ゲーム攻略・無料ウィキレンタルのアットウィキ (@WIKI)

USB_AUDIO@WIKI - Audio Device Document 1.0(101-105)

https://w.atwiki.jp/usb_audio/pages/49.html

原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 101 wProcessType Value CHORUS_PROCESS 0x05 DYN_RANGE_COMP_PROCESS 0x06 A.8 Audio Class-Specific Endpoint Descriptor Subtypes Table A-8 Audio Class-Specific Endpoint Descriptor Subtypes Descriptor Subtype Value DESCRIPTOR_UNDEFINED 0x00 EP_GENERAL 0x01 A.9 Audio Class-Specific Request Codes Table A-9 Audio Class-Specific Request Codes Class-Specific Request Code Value REQUEST_CODE_UNDEFINED 0x00 SET_ CUR 0x01 GET_ CUR 0x81 SET_ MIN 0x02 GET_ MIN 0x82 SET_ MAX 0x03 GET_ MAX 0x83 SET_ RES 0x04 GET_ RES 0x84 SET_MEM 0x05 GET_ MEM 0x85 GET_STAT 0xFF USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 102 A.10 Control Selector Codes A.10.1 Terminal Control Selectors Table A-10 Terminal Control Selectors Control Selector Value TE_CONTROL_UNDEFINED 0x00 COPY_PROTECT_CONTROL 0x01 A.10.2 Feature Unit Control Selectors Table A-11 Feature Unit Control Selectors Control Selector Value FU_CONTROL_UNDEFINED 0x00 MUTE_CONTROL 0x01 VOLUME_CONTROL 0x02 BASS_CONTROL 0x03 MID_CONTROL 0x04 TREBLE_CONTROL 0x05 GRAPHIC_EQUALIZER_CONTROL 0x06 AUTOMATIC_GAIN_CONTROL 0x07 DELAY_CONTROL 0x08 BASS_BOOST_CONTROL 0x09 LOUDNESS_CONTROL 0x0A A.10.3 Processing Unit Control Selectors A.10.3.1 Up/Down-mix Processing Unit Control Selectors Table A-12 Up/Down-mix Processing Unit Control Selectors Control Selector Value UD_CONTROL_UNDEFINED 0x00 UD_ENABLE_CONTROL 0x01 UD_MODE_SELECT_CONTROL 0x02 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 103 A.10.3.2 Dolby PrologicÔ Processing Unit Control Selectors Table A-13 Dolby Prologic Processing Unit Control Selectors Control Selector Value DP_CONTROL_UNDEFINED 0x00 DP_ENABLE_CONTROL 0x01 DP_MODE_SELECT_CONTROL 0x02 A.10.3.3 3D Stereo Extender Processing Unit Control Selectors Table A-14 3D Stereo Extender Processing Unit Control Selectors Control Selector Value 3D_CONTROL_UNDEFINED 0x00 3D_ENABLE_CONTROL 0x01 SPACIOUSNESS_CONTROL 0x03 A.10.3.4 Reverberation Processing Unit Control Selectors Table A-15 Reverberation Processing Unit Control Selectors Control Selector Value RV_CONTROL_UNDEFINED 0x00 RV_ENABLE_CONTROL 0x01 REVERB_LEVEL_CONTROL 0x02 REVERB_TIME_CONTROL 0x03 REVERB_FEEDBACK_CONTROL 0x04 A.10.3.5 Chorus Processing Unit Control Selectors Table A-16 Chorus Processing Unit Control Selectors Control Selector Value CH_CONTROL_UNDEFINED 0x00 CH_ENABLE_CONTROL 0x01 CHORUS_LEVEL_CONTROL 0x02 CHORUS_RATE_CONTROL 0x03 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 104 Control Selector Value CHORUS_DEPTH_CONTROL 0x04 A.10.3.6 Dynamic Range Compressor Processing Unit Control Selectors Table A-17 Dynamic Range Compressor Processing Unit Control Selectors Control Selector Value DR_CONTROL_UNDEFINED 0x00 DR_ENABLE_CONTROL 0x01 COMPRESSION_RATE_CONTROL 0x02 MAXAMPL_CONTROL 0x03 THRESHOLD_CONTROL 0x04 ATTACK_TIME 0x05 RELEASE_TIME 0x06 A.10.4 Extension Unit Control Selectors Table A-18 Extension Unit Control Selectors Control Selector Value XU_CONTROL_UNDEFINED 0x00 XU_ENABLE_CONTROL 0x01 A.10.5 Endpoint Control Selectors Table A-19 Endpoint Control Selectors Control Selector Value EP_CONTROL_UNDEFINED 0x00 SAMPLING_FREQ_CONTROL 0x01 PITCH_CONTROL 0x02 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 105 Appendix B. Example 1 USB Microphone (Informative) B.1 Product Description The device described here is a USB Microphone. It is a very simple device that has no Audio Controls incorporated. It delivers a mono audio data stream to the Host over its AudioStreaming interface. The used Audio Data Format is 16-bit 8KHz PCM. The synchronization type is Asynchronous Source. It uses its internal clock as a reference. The following figure presents the internal topology of the microphone. AudioStreaming Interface AudioControl Interface Audio Function Desktop Microphone IT OT USB IN Endpoint Figure B-1 USB Microphone Topology The audio function contains one Input Terminal that represents the actual microphone pick-up element, followed by the Analog-to-Digital Converter (ADC). The digital output stream of the ADC enters the audio function through the single Output Pin of the Input Terminal. Because there is no further processing on the audio stream, the Input Terminal is directly connected to the Input Pin of the Output Terminal. The Output Terminal is the representation within the audio function of the USB IN endpoint that eventually delivers the audio data stream to the Host. The internals of the audio function are presented to the Host through the (mandatory) AudioControl interface whereas the USB IN endpoint resides in the AudioStreaming interface. B.2 Descriptor Hierarchy This USB Microphone device includes the AudioControl interface (interface 0) and a single AudioStreaming interface (interface 1). The AudioStreaming interface features two alternate settings. The first alternate setting (Alternate Setting 0) has zero bandwidth associated with it so that switching to this alternate setting effectively frees all allocated bandwidth on the USB for this device. Zero bandwidth is indicated by the lack of a streaming endpoint. Alternate Setting 1 is the operational part of the interface and it has one isochronous IN endpoint. Figure presents the descriptor hierarchy. 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 ここを編集

Codeまとめby長谷川 - RFC5996(IKEv2)_2

https://w.atwiki.jp/code_matome/pages/39.html

2.9. Traffic Selector Negotiation When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a protect selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system s SPD is outside the scope of IKE, although some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). RFC4301準拠のIPsecサブシステムはSecurity Policy Database(SPD)の protect selectorにマッチするIP packetを受信したら、サブシステムはそのパケットをIPsecで保護する。SAがまだ存在しない場合、それを作成するのはIKEである。システムがSPDを管理する方法はIKEのスコープ外であるが、いくつかの実装はIKEの実行によりSPDを更新する（シナリオの例はSection 1.1.3参照）。 Kaufman, et al. Standards Track [Page 40] RFC 5996 IKEv2bis September 2010 Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. These must be communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] uses the SADB_ACQUIRE message). TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD. Traffic Selector(TS) payloadはendpointがpeerに自分のSPDの情報伝達することを可能とする。これらはSPDからIKEに伝えられること（例えばPF_KEY APIのSADB_ACQUIRE messageを使って）。TS payloadは新しいSAで転送されるpacketの選択基準を規定する。SPDの一貫性とSPDの動的な更新が保証される。 Two TS payloads appear in each of the messages in the exchange that creates a Child SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. 2つのTS payloadがChild SAのpairを作成するmessage exchangeで現れる。各TS payloadには1つ以上のTraffic Selectorが含まれる。各Traffic Selectorはaddress range(IPv4 or IPv6)、port range、IP protocol IDで構成される。 The first of the two TS payloads is known as TSi (Traffic Selector- initiator). The second is known as TSr (Traffic Selector-responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the Child SA pair. TSr specifies the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the Child SA pair. For example, if the original initiator requests the creation of a Child SA pair, and wishes to tunnel all traffic from subnet 198.51.100.* on the initiator s side to subnet 192.0.2.* on the responder s side, the initiator would include a single Traffic Selector in each TS payload. TSi would specify the address range (198.51.100.0 - 198.51.100.255) and TSr would specify the address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was acceptable to the responder, it would send identical TS payloads back. 最初のTS payloadはTSi(Traffic Selector-initiator)である。2つ目はTSr(Traffic Selector-responder)である。TSiはinitiatorのChild SAから受信するトラフィックのsource address、または送信するトラフィックのdestination addressを指定する。TSrはresponderのChild SAに送信するトラフィックのdestination address、または受信するsource addressを指定する。例えば、original initiatorがChild SAの作成を要求し、tunnelはinitiator side 198.51.100.*、responder sideは192.0.2.*を希望する場合、initiatorは各TS payloadに1つのTraffic Selectorを指定する。TSiはaddress range(198.51.100.0 - 198.51.100.255)で指定され、TSrはaddress range(192.0.2.0 - 192.0.2.255)で指定される。responderがその提案を許容した場合、同一のTS payloadを返す。 IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator. This could happen when the configurations of the two endpoints are being updated but only one end has received the new information. Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list. IKEv2ではinitiatorに提案されたtrafficのsubsetを選択することをresponderに許容する。これは2つのendpointで設定が更新され、片方でのみ新しい情報を受信したときに起こる可能性がある。2つのendpointが異なる人に設定される場合があるが、この不一致状態は問題なく継続する可能性がある。片方はtunnelにすべてのアドレスを設定し、もう片方のlist更新に依存するような構成も可能とする。 When the responder chooses a subset of the traffic proposed by the initiator, it narrows the Traffic Selectors to some subset of the initiator s proposal (provided the set does not become the null set). If the type of Traffic Selector proposed is unknown, the responder ignores that Traffic Selector, so that the unknown type is not returned in the narrowed set. responderがinitiatorから提案されたtrafficのsubsetを選択すると、initiatorの提案（null setではない）を狭くしたTraffic Selectorになる。提案されたTraffic Selectorが不明な場合、範囲を狭くしたsetを返さないようにするため、responderはTraffic Selectorを無視する。 Kaufman, et al. Standards Track [Page 41] RFC 5996 IKEv2bis September 2010 To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. In the example, the initiator would include in TSi two Traffic Selectors the first containing the address range (198.51.100.43 - 198.51.100.43) and the source port and IP protocol from the packet and the second containing (198.51.100.0 - 198.51.100.255) with all ports and IP protocols. The initiator would similarly include two Traffic Selectors in TSr. If the initiator creates the Child SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr can be ranges rather than specific values. このケースでresponderが適切な範囲を選択できるようにするため、initiatorがdata packetをSAに送信要求した場合、initiatorはTSiとTSrのTraffic Selectorとして、initiatorは特定のアドレスをTraffic Selectorに含める。例えば、initiatorがTSiに2つのTraffic Selector、1つ目(198.51.100.43 - 198.51.100.43)とsource portとIP protocol、2つ目(198.51.100.0 - 198.51.100.255) と全てのportとIP protocol。initiarotは同じ2つTraffic Selector TSrを含むこととする。initiatorは2つのTraffic SelectorをTSiに含むこととする。initiatorが対向からのメッセージ無しにChild SAを作成する場合、起動時にはinitiatorのtunnelには特定のアドレスが無い場合がある。その場合はTSi/TSrの最初の値はその値としてよい。 The responder performs the narrowing as follows responderは下記のように範囲を狭める。 o If the responder s policy does not allow it to accept any part of the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE Notify message. responderのpolicyが提案されたTraffic Selectorの一部でも許可しない場合、TS_UNACCEPTABLE Notify messageを応答する。 o If the responder s policy allows the entire set of traffic covered by TSi and TSr, no narrowing is necessary, and the responder can return the same TSi and TSr values. responderのpolicyがTSiとTSrに完全に一致した場合、範囲を狭める必要はなく、responderは同じTSiとTSrを返す。 o If the responder s policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the Traffic Selectors to a subset that includes the initiator s first choices. In this example above, the responder might respond with TSi being (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. responderのpolicyがTSiとTSrの最初のselectorを許容する場合、Traffic Selectorの範囲をinitiatorの最初の選択に狭める。例の場合、responderはTSi(198.51.100.43 - 198.51.100.43) with all ports and IP protocolを応答する。 o If the responder s policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. responderのpolicyが最初のTSiとTSrのselectorを許容しない場合、responderは許容するTSiとTSrのsubsetに狭める。 When narrowing is done, there may be several subsets that are acceptable but their union is not. In this case, the responder arbitrarily chooses one of them, and MAY include an ADDITIONAL_TS_POSSIBLE notification in the response. The ADDITIONAL_TS_POSSIBLE notification asserts that the responder narrowed the proposed Traffic Selectors but that other Traffic Selectors would also have been acceptable, though only in a separate SA. There is no data associated with this Notify type. This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. 範囲狭めが行われる場合、いくつかのsubsetがあるが、それらはunion（和集合）でない可能性がある。その場合、responderはそれらの中の1つを選択し、応答にADDITIONAL_TS_POSSIBLE notificationを含めてよい。ADDITIONAL_TS_POSSIBLE notificationはresponderが提案されたTraffic Selectorを狭めたが、他のTraffic SelectorもそのSAで許容されることを示す。このNotfyに関連付けられるデータはない。このケースは、initiatorとresponderが異なる構成をされたときに発生する。initiatorとresponderがtunnelの設定で合意している場合、initiatorがresponderが許容するより広いtunnelを要求することはない。 Kaufman, et al. Standards Track [Page 42] RFC 5996 IKEv2bis September 2010 It is possible for the responder s policy to contain multiple smaller ranges, all encompassed by the initiator s Traffic Selector, and with the responder s policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated Child SA. If the initiator didn t generate its request based on the packet, but (for example) upon startup, there would not be the very specific first Traffic Selectors helping the responder to select the correct range. There would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a SINGLE_PAIR_REQUIRED Notify message. responderのpolicyに小さい複数のrangeを含むことができ、すべてinitiatorのTraffic Selectorに含まれ、responderのpolicyは異なるSAで送信される。上記例では、responderは希望のinitiatorとのtunnelのアドレスのpolocyを持っているかもしれないが、各アドレスのpairがそれぞれChild SAである必要がある。responderがtunnelに含まれるべきaddressを決めるための方法はないため、そのときはSINGLE_PAIR_REQUIRED Notify messageでrequestをrejectすること。 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA request is unacceptable because its sender is only willing to accept Traffic Selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward. SINGLE_PAIR_REQUIRED errorは送信者が1つのアドレスのpairのTraffic Selectorのみを許容するため、CREATE_CHILD_SA requestを許容しないことを示す。requesterはforwardするtrafficのために、SAのrequestを応答することを期待する。 Few implementations will have policies that require separate SAs for each address pair. Because of this, if only some parts of the TSi and TSr proposed by the initiator are acceptable to the responder, responders SHOULD narrow the selectors to an acceptable subset rather than use SINGLE_PAIR_REQUIRED. 実装では、各アドレスのpairに別々のSAを必要とするpolicyがあってよい。そのため、initiatorから複数ペアのTSi/TSrが提案され、responderに許容される場合、responderはselectorの範囲を狭めるのではなく、SINGLE_PAIR_REQUIREDを使用すること。 2.9.1. Traffic Selectors Violating Own Policy When creating a new SA, the initiator needs to avoid proposing Traffic Selectors that violate its own policy. If this rule is not followed, valid traffic may be dropped. If you use decorrelated policies from [IPSECARCH], this kind of policy violations cannot happen. 新しいSAを作る際、initiatorは自分のpolicyに違反するTraffic Selectorを提案しないことが必要である。このルールに従わないと有効なtrafficがdropする可能性がある。[IPSECARCH]のポリシーを使用する場合はこのようなpolicy違反は起きない。 This is best illustrated by an example. Suppose that host A has a policy whose effect is that traffic to 198.51.100.66 is sent via host B encrypted using AES, and traffic to all other hosts in 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also that host B accepts any combination of AES and 3DES. これは例で示される。host Aはtraffic 198.51.100.66はhost Bを経由してAESで暗号化して送信する。他の198.51.100.0/24のhostへのtrafficは3DESで暗号化してhost B経由で送信する。host BはAES/3DESの任意の組み合わせを受け入れる。 If host A now proposes an SA that uses 3DES, and includes TSr containing (198.51.100.0-198.51.100.255), this will be accepted by host B. Now, host B can also use this SA to send traffic from 198.51.100.66, but those packets will be dropped by A since it requires the use of AES for this traffic. Even if host A creates a new SA only for 198.51.100.66 that uses AES, host B may freely continue to use the first SA for the traffic. In this situation, when proposing the SA, host A should have followed its own policy, and included a TSr containing ((198.51.100.0- 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. host Aが3DES、TSr (198.51.100.0-198.51.100.255)の新しいSAを提案し、host Bが許容したとする。host BはこのSAで198.51.100.66からのtrafficを送信するが、Aでdropされる。なぜなら、そのtrafficはAESを使用する必要があるためである。host Aが198.51.100.66のためだけにAESの新しいSA作った場合でもhost Bはtrafficのために最初のSAを使用し続けてもよい。この場合、SAを提案したとき、host Aは下記のpolicyを維持し、TSrに下記を含める必要がある((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) 。 In general, if (1) the initiator makes a proposal for traffic X (TSi/TSr), do SA , and (2) for some subset X of X, the initiator does not actually accept traffic X with SA, and (3) the initiator would be willing to accept traffic X with some SA (!=SA), valid traffic can be unnecessarily dropped since the responder can apply either SA or SA to traffic X . 一般的に、(1)initiatorがSAにtraffic X（TSi/TSr）のproposalをした場合、 (2)Xのsubset X をinitiatorがSAでtraffic許容しない (3)initiatorがSA (!=SA)でtraffic X を許容する responderはtraffic X にSAかSA どちらでも適用することができるため、正当なtrafficがdropされる可能性がある。 2.10. Nonces The IKE_SA_INIT messages each contain a nonce. These nonces are used as inputs to cryptographic functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain nonces. These nonces are used to add freshness to the key derivation technique used to obtain keys for Child SA, and to ensure creation of strong pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF). However, the initiator chooses the nonce before the outcome of the negotiation is known. Because of that, the nonce has to be long enough for all the PRFs being proposed. If the same random number source is used for both keys and nonces, care must be taken to ensure that the latter use does not compromise the former. IKE_SA_INITメッセージはそれぞれnonceを含む。nonceは暗号化への入力として使用される。CREATE_CHILD_SA requestとCREATE_CHILD_SA responseもnonceを含む。このnonceは新たなChild SA用のkey算出とDiffie-Hellman keyから安全な乱数を生成するために使用される。IKEv2のnonceはランダムに選択されること。サイズは128bit以上で、ネゴシエーションされたPRFの半分以上のキーサイズであること。ただし、ネゴシエーションの前にinitiatorがnonceを送信する。その際はサポートするPRFに対して十分な長さのnonceを選択すること。 2.11. Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses over which it runs. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. IKE functions identically over IPv4 or IPv6. IKEはUDP port 500/4500で動作し、同じIPアドレスでESP/AHも動作する。outer headerのIP addressとportはcryptographically protectされず、IKEはNAT box上でも動作するように設定されている。実装はsource portが500/4500でなくても受信を許容すること。また、そのaddress/portの要求に応答すること。responseのsource addressとportは受信したrequestに従って設定する。IKEはIPv4/IPv6で動作する。 2.12. Reuse of Diffie-Hellman Exponentials IKE generates keying material using an ephemeral Diffie-Hellman exchange in order to gain the property of perfect forward secrecy . This means that once a connection is closed and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the two endpoints cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space. IKEはPFS（perfect forward secrecy）のためDiffie-Hellman鍵交換を使用して鍵を生成する。これは通信を傍受されても総当りでないと解読できないということである。 perfect forward secrecy：異なる暗号キーの対から生成したキーが、片方の暗号キーだけからは総当り以外で解読できないこと。 Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys. PFSの達成のためには接続が閉じられた時、接続で使用されたキーだけでなく再計算に使用する乱数なども消去する必要がある。 Because computing Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups. There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state. Diffie-Hellman exponentialsの計算は計算量が多いため、複数の接続setup時にDiffie-Hellman exponentialsを再利用してもよい。これにはいくつかの合理的理由がある。endpointはあるconnectionがexponentialのlifetimeより短いならばless-than-perfect forward secrecyとなるが、周期的に新しいexponetntialを選択することができる。また、exponentialは各connectionで使用されたのをトレースでき、関連するconnectionがcloseしたときに関連する情報が削除される。これにより、perfect forward secrecyを失うことなくexponentialを再利用することができる。 Whether and when to reuse Diffie-Hellman exponentials are private decisions in the sense that they will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation. See [REUSE] for a security analysis of this practice and for additional security considerations when reusing ephemeral Diffie-Hellman keys. Diffie-Hellman exponentialを再利用するかどうかは相互運用性に影響はないので決定次第である。exponentialを再利用する実装は、計算を省略するため対向endpointの過去のexchangeで使用されたexponentialを記憶してよい。[REUSE]はephemeral Diffie-Hellman keyの再利用に関する議論とセキュリティ分析をしている。 2.13. Generating Keying Material In the context of the IKE SA, four cryptographic algorithms are negotiated an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF). The PRF is used for the construction of keying material for all of the cryptographic algorithms used in both the IKE SA and the Child SAs. IKE SAでは4つの暗号化アルゴリズムがネゴシエーションされる。 Encryption Algorithm、Integrity Protection Algorithm、Diffie-Hellman group、Pseudorandom funtion（PRF） PRFはIKE SA、Child SAのすべての暗号化アルゴリズムのkeying materialの生成に使用される。 We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key. For algorithms that accept a variable-length key, a fixed key size MUST be specified as part of the cryptographic transform negotiated (see Section 3.3.5 for the definition of the Key Length transform attribute). For algorithms for which not all values are valid keys (such as DES or 3DES with key parity), the algorithm by which keys are derived from arbitrary values MUST be specified by the cryptographic transform. encryption、integrity protectionはキー長が固定で、ランダムに選択されたその値がキーとして機能することを前提とする。可変長のキーを許容するアルゴリズムについては、固定キーサイズのtranfsormのネゴシエーションのときに規定すること（Section 3.3.5のKey Length transform attributeの定義参照）。全ての値がkeyにならないアルゴリズム（DESや3DESのkey parityなど）については、transformによって規定されること。 Kaufman, et al. Standards Track [Page 45] RFC 5996 IKEv2bis September 2010 For integrity protection functions based on Hashed Message Authentication Code (HMAC), the fixed key size is the size of the output of the underlying hash function. HMACにもとづくintegrity protectionは固定キーサイズがハッシュ関数の出力サイズになる。 It is assumed that PRFs accept keys of any length, but have a preferred key size. The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based on the HMAC construction, the preferred key size is equal to the length of the output of the underlying hash function. Other types of PRFs MUST specify their preferred key size. PRFは任意のキー長を許容するが、適切なkey長がある。適切なkey長はSK_d、SK_pi、SK_prに使用すること。HMACに基づくPRFはもとになるハッシュ関数の出力長に適切なkey長に等しい。他のPRFは適切なkey sizeを指定する必要がある。 Keying material will always be derived as the output of the negotiated PRF algorithm. Since the amount of keying material needed may be greater than the size of the output of the PRF, the PRF is used iteratively. The term prf+ describes a function that outputs a pseudorandom stream based on the inputs to a pseudorandom function called prf . keying materialはネゴシエーションされたPRFアルゴリズムの出力として導出される。key material sizeはPRFのサイズより大きくできるので、その場合はPRFを繰り返す。prf+はprfという擬似乱数関数(pseudorandom function)である。 In the following, | indicates concatenation. prf+ is defined as |は連結を表す。prf+は下記のように定義される。 prf+ (K,S) = T1 | T2 | T3 | T4 | ... where T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) ... This continues until all the material needed to compute all required keys has been output from prf+. The keys are taken from the output string without regard to boundaries (e.g., if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key will come from T1 and the beginning of T2, while the HMAC key will come from the rest of T2 and the beginning of T3). 必要なすべてのkeyのmaterialがprf+から出力されるまで続く。keyは境界に関係なく出力stringから取得される。（key 256bitのAES key、160bit HMAC key、prf functionが160bitを生成する場合、AES keyはT1とT2、HMAC keyはT2とT3から計算される。） 256bit=32octet 160bit=20octet T1、T2、T3=20octet The constant concatenated to the end of each prf function is a single octet. The prf+ function is not defined beyond 255 times the size of the prf function output. prf+はprf関数の出力サイズの255倍を超えて定義しないこと。 2.14. Generating Keying Material for the IKE SA The shared keys are computed as follows. A quantity called SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that exchange. SKEYSEED is used to calculate seven other secrets SK_d used for deriving new keys for the Child SAs established with this IKE SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges; SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are used when generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr MUST be the preferred key length of the PRF agreed upon. shared keyは下記のように計算される。 SKEYSEEDはIKE_SA_INIT exchangeのnonceとDiffie-Hellmanで計算される。SKEYSEEDは7つのkeyを計算するために使用される。 SK_dはChild SAのkeyの計算に使う。 SK_ai、SK_arはIKE SA（Encrypted payload）の完全性保証の認証データ計算用のkey。 SK_ei、SK_erはIKE SA（Encrypted payload）の暗号化のkey。 SK_pi、SK_prはAuthentication payloadの生成に使用するkey。 SK_d、pi、prはネゴシエーションしたPRFの長さであること。 SKEYSEED and its derivatives are computed as follows SKEYSEEDと派生値は下記のように計算される。 SKEYSEED = prf(Ni | Nr, g^ir) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. g^ir is represented as a string of octets in big endian order padded with zeros if necessary to make it the length of the modulus. Ni and Nr are the nonces, stripped of any headers. For historical backward-compatibility reasons, there are two PRFs that are treated specially in this calculation. If the negotiated PRF is AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], only the first 64 bits of Ni and the first 64 bits of Nr are used in calculating SKEYSEED, but all the bits are used for input to the prf+ function. SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_prはprf+で生成されるbitを順に取って作成される。 g^irはDiffie-Hellman鍵交換の共有秘密鍵。g^irはmodulusの長さにするため必要であれば0でpaddingしてビッグエンディアンのoctet文字として表現する。Ni/Nrはnonceで全てのheaderを取り除いたもの。下位互換のため、2つのPRFは特別な扱いで計算される。ネゴシエーションされたPRFがAES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128]の場合、Niの最初の64bitとNrの最初の64bitがSKEYSEEDの計算に使用され、すべてのbitがprf+の入力に使用される。 The two directions of traffic flow use different keys. The keys used to protect messages from the original initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er. 双方向のtrafficで異なる鍵が使われる。original initiatorからのmessageを保護するのはSK_ai/SK_eiである。逆方向からのmessageを保護するのはSK_ar/SK_erである。 2.15. Authentication of the IKE SA When not using extensible authentication (see Section 2.16), the peers are authenticated by having each sign (or MAC using a padded shared secret as the key, as described later in this section) a block of data. In these calculations, IDi and IDr are the entire ID payloads excluding the fixed header. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message (IKE_SA_INIT response) and end with the last octet of the last payload in the second message. Appended to this (for the purposes of computing the signature) are the initiator s nonce Ni (just the value, not the payload containing it), and the value prf(SK_pr, IDr ). Note that neither the nonce Ni nor the value prf(SK_pr, IDr ) are transmitted. Similarly, the initiator signs the first message (IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder s nonce Nr, and the value prf(SK_pi, IDi ). It is critical to the security of the exchange that each side sign the other side s nonce. EAP認証(Section 2.16参照)を使用しない場合、peerはそれぞれのデータブロックの署名（または後述するshared secret keyのMACをkeyとして使用して）によって認証をする。この計算にはID payloadの固定長ヘッダを除いたIDi /IDr が使用される。 Responderの場合、IKE_SA_INIT response(Message2)のヘッダの最初のSPI～最後のpayloadのoctetまでを署名する。署名するためinitiatorのnonce Ni（値だけでpaylaod全体は含まない）とprf(SK_pr、IDr)を結合する。Niとprf(SK_pr, IDr )のどちらかだけが送信されることに注意せよ。同様にInitiatorはIKE_SA_INIT request(Message1)の最初のヘッダのSPI～最後のpayloadのoctetまでを署名する。署名するためresponderのnonce Nrとprf(SK_pi、IDi )を結合する。両側が相手のnonceで署名することがexchnageの機密性で重要である。 The initiator s signed octets can be described as initiatorの署名オクテットは下記で示される。 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) The responder s signed octets can be described as responderの署名オクテットは下記で示される。 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload) Note that all of the payloads are included under the signature, including any payload types not defined in this document. If the first message of the exchange is sent multiple times (such as with a responder cookie and/or a different Diffie-Hellman group), it is the latest version of the message that is signed. このドキュメントに含まれないすべてのpayloadが署名に含まれることに注意せよ。exchnageの最初のメッセージが複数回送信される場合（responder cookieや異なるDiffie-Hellman group要求の場合）、最新（最後に送られた）のメッセージが署名に使用される。 Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. The signature or MAC will be computed using algorithms dictated by the type of key used by the signer, and specified by the Auth Method field in the Authentication payload. There is no requirement that the initiator and responder sign with the same cryptographic algorithms. The choice of cryptographic algorithms depends on the type of key each has. In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate. It will commonly be the case (but it is not required) that, if a shared secret is used for authentication, the same key is used in both directions. オプションでID payloadのディジタル署名の計算に使用される証明書、証明書 chainをmessage3、message4に含んでよい。署名またはMACはAuthentication payloadのAuth Method filedで指定されるアルゴリズムによって計算される。responderとinitiatorが同じ暗号アルゴリズムで署名をするという要件はない。暗号化アルゴリズムの選択はkey typeによって決まる。initiatorは共有鍵、responderは公開鍵と証明書となってもよい。必須ではないが、shared secretを認証に使用する場合は両方向で同じkeyを使用する。 Kaufman, et al. Standards Track [Page 48] RFC 5996 IKEv2bis September 2010 Note that it is a common but typically insecure practice to have a shared key derived solely from a user-chosen password without incorporating another source of randomness. This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. (Applications using password-based authentication for bootstrapping and IKE SA should use the authentication method in Section 2.16, which is designed to prevent off-line dictionary attacks.) The pre- shared key needs to contain as much unpredictability as the strongest key being negotiated. In the case of a pre-shared key, the AUTH value is computed as 乱数を用いず、ユーザが選択したパスワードのみによるshared keyは危険であるということに注意すること。ユーザが選択したパスワードは辞書攻撃に対して安全ではない。off-line辞書攻撃を防ぐ認証方式はSection 2.16の認証方式を使用する必要がある。pre-shared keyは長いkeyがネゴシエーションされたときと同様の予測不可能正を含んでいる必要がある。pre-shared keyのAUTH valueは下記で計算される。 For the initiator AUTH = prf( prf(Shared Secret, Key Pad for IKEv2 ), ) For the responder AUTH = prf( prf(Shared Secret, Key Pad for IKEv2 ), ) where the string Key Pad for IKEv2 is 17 ASCII characters without null termination. The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret, Key Pad for IKEv2 ), which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. The management interface by which the shared secret is provided MUST accept ASCII strings of at least 64 octets and MUST NOT add a null terminator before using them as shared secrets. It MUST also accept a hex encoding of the shared secret. The management interface MAY accept other encodings if the algorithm for translating the encoding to a binary string is specified. Key Pad for IKEv2 はnull終端なしの17文字 ASCII文字である。Shared secretは可変長である。shared secretがパスワードから導出される場合、IKEの実装は平文でパスワードを保存するのではなく、prf(Shared Secret, Key Pad for IKEv2 )として格納する。shared secretのため、management interfaceは少なくとも64 octetのnull終端を除いたASCII文字を許容すること。また、hexエンコーディングのshared secretを許容すること。バイナリ文字にエンコードするアルゴリズムが指定される場合、management interfaceはそれを許容してもよい。 There are two types of EAP authentication (described in Section 2.16), and each type uses different values in the AUTH computations shown above. If the EAP method is key-generating, substitute master session key (MSK) for the shared secret in the computation. For non-key-generating methods, substitute SK_pi and SK_pr, respectively, for the shared secret in the two AUTH computations. 2種類あるEAP authentication（Section 2.16参照）は上記と異なるAUTHを用いる。EAP methodがkey-generatingの場合はshared secretではなくmaster session key(MSK)を用いる。non-key-generating methodの場合は2つのAUTHの計算に使用するshared secretの代わりにSK_piとSK_prをそれぞれ用いる。 Kaufman, et al. Standards Track [Page 49] RFC 5996 IKEv2bis September 2010 2.16. Extensible Authentication Protocol Methods In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public-key-signature-based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as Legacy Authentication mechanisms. 公開鍵署名と共有鍵の認証に加え、IKEはRFC3748のEAPによる認証をサポートする。EAPは非対称（サーバがユーザを認証するために設計された）であり、対等ではない。EAPはinitiatorをresponderが認証するために使用され、公開鍵署名ベースの認証と組み合わせて使用されること。これらのmethodは Legacy Authentication mechanismに関連している。 While this document references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here. [EAP] defines an authentication protocol requiring a variable number of messages. Extensible Authentication is implemented in IKE as additional IKE_AUTH exchanges that MUST be completed in order to initialize the IKE SA. 新しいmethodは[EAP]に追加され、本ドキュメントでは単純なバリエーションのみ説明する。[EAP]は可変数のメッセージによる認証プロトコルを定義している。EAPはIKE SAを作成するために実行されるIKE_AUTH exchangeとしてIKEで実装される。 An initiator indicates a desire to use EAP by leaving out the AUTH payload from the first message in the IKE_AUTH exchange. (Note that the AUTH payload is required for non-EAP authentication, and is thus not marked as optional in the rest of this document.) By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an EAP method, it will place an Extensible Authentication Protocol (EAP) payload in the response of the IKE_AUTH exchange and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange. In the case of a minimal EAP method, the initial SA establishment will appear as follows initiatorはIKE_AUTH exchangeの最初のメッセージのAUTH payloadでEAPの使用要求を示す。AUTH paylaodは非EAP認証でも使用されるため、オプションとしては扱われないことに注意。IDiを含むがAUTH payloadを含まない場合、identityが認証されたことにはならない。respondeがEAPを使用すると決定した場合、IKE_AUTH exchangeにEAP paylaodで応じ、IKE_AUTH exchangeでinitiatorの認証が完了するまでSAr2、TSi、TSrの送信を続ける。最小のEAP手順では下記のようにSAが確立される。 Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni -- -- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} -- -- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} -- -- HDR, SK {EAP (success)} HDR, SK {AUTH} -- -- HDR, SK {AUTH, SAr2, TSi, TSr } Kaufman, et al. Standards Track [Page 50] RFC 5996 IKEv2bis September 2010 As described in Section 2.2, when EAP is used, each pair of IKE SA initial setup messages will have their message numbers incremented; the first pair of AUTH messages will have an ID of 1, the second will be 2, and so on. Section 2.2の通り、EAPを使用した場合、最初のAUTHメッセージのpairはmessage ID 1、次は2とmessage numberがインクリメントされる、 For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the initiator and responder to generate AUTH payloads in messages 7 and 8 using the syntax for shared secrets specified in Section 2.15. The shared key from EAP is the field from the EAP specification named MSK. This shared key generated during an IKE exchange MUST NOT be used for any other purpose. EAPでは認証のためshared keyが生成される。shared keyのsyntaxはSection 2.15で規定され、message 7と8のAUTH payloadから initiator/responder双方で生成され、使用される。EAPで共有されるキーはMSKという名前のEAPの仕様のものである。IKE exchangeで生成されたこのshared keyは他の目的では使用しないこと。 EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks [EAPMITM] if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, the AUTH payloads in messages 7 and 8 MUST be generated using SK_pi and SK_pr, respectively. shared keyを使用しないEAP methodは使用しないこと。server-authenticated tunnelを使用しないEAP methodを使用した場合、man-in-the-middle攻撃[EAPMITM]の対象となるため。詳細はSecurity Consideration section参照。shared keyを使用しないEAPを使用する場合、message7と8のAUTH payloadはSK_pi、SK_prから生成されること。 The initiator of an IKE SA using EAP needs to be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the responder sends notification messages and/or retries the authentication prompt. Once the protocol exchange defined by the chosen EAP authentication method has successfully terminated, the responder MUST send an EAP payload containing the Success message. Similarly, if the authentication method has failed, the responder MUST send an EAP payload containing the Failure message. The responder MAY at any time terminate the IKE exchange by sending an EAP payload containing the Failure message. EAPを使用したIKE SAのinitiatorはresponderがリトライ/notification送信した場合、少なくとも10 IKE_AUTH exchange、initial protocol exchnageを延長できる必要がある。選択したEAP認証methodが成功した後、responderはEAP (success messageを含む)を送信する。同様に、認証methodが失敗した場合はresponderはEAP payload(failure messageを含む)を送信する。responderはいつでもEAP payload(failure messageを含む)によりIKE exchangeを終了できる。 Following such an extended exchange, the EAP AUTH payloads MUST be included in the two messages following the one containing the EAP Success message. 以下のようにEAP exchangeでは、EAP AUTH payloadは1つのEAP Success messageを含む2メッセージを送信すること。 When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity, if different from that in the IDi payload, has to be sent from the AAA server to the IKEv2 responder. initiatorがEAP認証を使用する場合、IDi payloadをAAAのルーティングと使用するEAP medhodの選択に使用してよい。IDiはEAPによって認証されるIDと異なってよい。policy、アクセス制御は実際にEAPで認証されたIDを用いること。多くの場合、EAPサーバはIKE responderと別のAAAサーバに実装される。認証されたIDがIDi payloadと異なる場合、認証されたIDはAAAサーバからIKEv2 responderに送信される。 Kaufman, et al. Standards Track [Page 51] RFC 5996 IKEv2bis September 2010 2.17. Generating Keying Material for Child SAs A single Child SA is created by the IKE_AUTH exchange, and additional Child SAs can optionally be created in CREATE_CHILD_SA exchanges. Keying material for them is generated as follows 一つのChild SAはIKE_AUTH exchangeで作成され、追加のChild SAはオプションでCREATE_CHILD_SA exchageで作成される。下記のようにkeying materialが作成される。 KEYMAT = prf+(SK_d, Ni | Nr) Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this request is the first Child SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation. 最初のChild SAの場合はIKE_SA_INITのNi/Nrを使用し、追加のChild SAの場合はCREATE_CHILD_SAのNi/Nrが使用される。 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman exchange, the keying material is defined as オプションのDiffie-Hellman exchangeを含むCREATE_CHILD_SA exchnageは下記のように計算される。prf+は必要な鍵長になるまで繰り返される。 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros in the high-order bits if necessary to make it the length of the modulus). g^ir(new)はCREATE_CHILD_SA exchangeのDiffie-Hellman exchangeによる新しい共有秘密である。（必要なmodulus長にするため、必要ならば上位ビットを0で埋め、big endianでoctet stringで表される。） A single CHILD_SA negotiation may result in multiple Security Associations. ESP and AH SAs exist in pairs (one in each direction), so two SAs are created in a single Child SA negotiation for them. Furthermore, Child SA negotiation may include some future IPsec protocol(s) in addition to, or instead of, ESP or AH (for example, ROHC_INTEG as described in [ROHCV2]). In any case, keying material for each Child SA MUST be taken from the expanded KEYMAT using the following rules 1つのCHILD_SAネゴシエーションで複数のSAが作られる場合がある。ESP/AH SAはpait（各方向に1個ずつ）なので、単一のChild SAのネゴシエーションで2つのSAが作成される。さらに、Child SAネゴシエーションはEPS/AH以外に、今後の仕様を含められる(例えばROHC_INTEGなど)。いずれの場合もChild SAのkeying matrialは下記によりKEYMATから取得される。 o All keys for SAs carrying data from the initiator to the responder are taken before SAs going from the responder to the initiator. initiatorからresponderにデータを送信するための全てのkeyはresponderからinitiatorへのSAの前に作成される。 o If multiple IPsec protocols are negotiated, keying material for each Child SA is taken in the order in which the protocol headers will appear in the encapsulated packet. 複数のIPsecプロトコルがネゴシエーションされる場合、各Child SAのkeying materialはカプセル化されたprotocol headerの順に取り出される。 o If an IPsec protocol requires multiple keys, the order in which they are taken from the SA s keying material needs to be described in the protocol s specification. For ESP and AH, [IPSECARCH] defines the order, namely the encryption key (if any) MUST be taken from the first bits and the integrity key (if any) MUST be taken from the remaining bits. IPsec protocolが複数のキーを必要とする場合、keying materialを取得する順番はprotocolの仕様に記載される必要がある。ESP/AHは通常、encryption keyがあれば最初に取得し、integrity keyがあれば残ったbitから取得する。 Kaufman, et al. Standards Track [Page 52] RFC 5996 IKEv2bis September 2010 Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm, or negotiated in SA payloads (see Section 2.13 for description of key lengths, and Section 3.3.5 for the definition of the Key Length transform attribute). 各cryptographic algorithmはalgorithmで定義されるか、SA payloadでネゴシエーションされた固定bitのkeying materialを取得する。（Section 2.13にkeylengthの説明、Section 3.3.5にはKey Length transform attributeの説明を記載する。） 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA (see Sections 1.3.2 and 2.8). New initiator and responder SPIs are supplied in the SPI fields in the Proposal structures inside the Security Association (SA) payloads (not the SPI fields in the IKE header). The TS payloads are omitted when rekeying an IKE SA. SKEYSEED for the new IKE SA is computed using SK_d from the existing IKE SA as follows CREATE_CHILD_SA exchangeは既存のIKE SAのrekeyに使用される（Section 1.3.2、2.8参照）。新しいinitiator SPIとresponder SPIはIKE headerのSPI fieldでなく、SA payloadのProposalのSPI filedで提供される。IKE SAをrekeyするときTS payloadは省略される。新しいIKE SAのSKEYSEEDは下記のように既存のIKE SAのSK_dを使用して計算される。 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros if necessary to make it the length of the modulus) and Ni and Nr are the two nonces stripped of any headers. g^ir(new)はCREATE_CHILD_SA exchangeのDiffie-Hellman exchangeによる新しい共有秘密であり（必要なmodulus長にするため、必要ならば上位ビットを0で埋め、big endianでoctet stringで表される。）、Ni/Nrはheaderから取得された2つのnonceである The old and new IKE SA may have selected a different PRF. Because the rekeying exchange belongs to the old IKE SA, it is the old IKE SA s PRF that is used to generate SKEYSEED. 新旧のIKE SAが異なるPRFを選択してもよい。rekey exchangeは古いIKE SAで実施されるため、SKEYSEEDを生成するのに使用されるSAのPRFはold IKEである。 The main reason for rekeying the IKE SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. Therefore, implementations MUST perform a new Diffie-Hellman exchange when rekeying the IKE SA. In other words, an initiator MUST NOT propose the value NONE for the Diffie-Hellman transform, and a responder MUST NOT accept such a proposal. This means that a successful exchange rekeying the IKE SA always includes the KEi/KEr payloads. IKE SAをrekeyする主な理由は、古いkeying materialが現在のkeyによって危殆化すること、またはその逆を防ぐためである。従って、実装はIKE SAのrekeyの場合、新しいDiffie-Hellman exchangeを実行すること。言い換えると、initiatorは NONE にしたDiffie-Hellman transformを提案しないこと。また、responderはそのようなproposalを許容しないこと。これは、IKE SAのrekayの成功したexchangeは常にKEi/KEr payloadを含むことを意味する。 The new IKE SA MUST reset its message counters to 0. 新しいIKE SAはmessage counterを0にリセットすること。 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new exchange, and using the new IKE SA s PRF. 新しいexchangeのSPIr、SPIr、Ni、Nrと新しいIKE SAのPRFが使われ、Section 2.14の方法でSK_d, SK_ai, SK_ar, SK_ei, and SK_erがSKEYSEEDが計算される。 2.19. Requesting an Internal Address on a Remote Network Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. A request for such a temporary address can be included in any request to create a Child SA (including the implicit request in message 3) by including a CP payload. Note, however, it is usual to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA. endpoint-to-security-gatewayのシナリオでは保護されたネットワーク内のIPアドレスを動的に割り当てる必要になるシナリオが発生することが多い。一時的なアドレスの要求はCP payloadでChild SA作成の要求（message 3に含まれる）に含めることができる。IKE_AUTH exchangeで一つのアドレスのみを割り当てるのが一般的である。そのアドレスはIKE SAが削除されるまでは最低限、維持される。 This function provides address allocation to an IPsec Remote Access Client (IRAC) trying to tunnel into a network protected by an IPsec Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled address (and optionally other information concerning the protected network) in the IKE_AUTH exchange. The IRAS may procure an address for the IRAC from any number of sources such as a DHCP/BOOTP (Bootstrap Protocol) server or its own address pool. この機能はIPsecリモートアクセスサーバー(IRAS)によって、保護されたネットワークトンネルからのIPsecリモートアクセスクライアント(IRAC)へのアドレス割り当てを提供する。IKE_AUTH exchangeはIKE SAとChild SAを作成するため、IRACはIKE_AUTH exchangeでIRAC-controlled address（および保護されたネットワークに関するその他の情報（netmask等））を要求すること。 IRASはDHCP/BOOTP(Bootstrap Protocol)サーバーや独自のアドレスプールなどによりIRACにアドレスを割り当ててよい。 Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -- -- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} In all cases, the CP payload MUST be inserted before the SA payload. In variations of the protocol where there are multiple IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages containing the SA payloads. すべてのケースでCP payloadはSA payloadの前に設定されること、複数のIKE_AUTH exchangeを含む場合、CP payloadはSA payloadを含むメッセージの前に含まれること。 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY contain any number of additional attributes the initiator wants returned in the response. CP(CFG_REQUEST)は少なくとも一つのINTERNAL_ADDRESS attributeを含むこと。それ以外にもinitiatorが応答で返送を必要とするattributeを含んでよい。 Kaufman, et al. Standards Track [Page 54] RFC 5996 IKEv2bis September 2010 For example, message from initiator to responder 例えば下記のメッセージがinitiatorからresponderに送信された場合。 CP(CFG_REQUEST)= INTERNAL_ADDRESS() TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255) NOTE Traffic Selectors contain (protocol, port range, address range). NOTE Traffic Selectorを含む。（protocol、portの範囲、addessの範囲） Message from responder to initiator resoonderからinitiatorへのメッセージ。 CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255) All returned values will be implementation dependent. As can be seen in the above example, the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST) and MAY ignore the non- mandatory attributes that it does not support. すべての戻り値は実装に依存する。上記の例のように、IRASはCP(CFG_REQUEST)に含まれていないattributeを送信してよいし、サポートしていないnon-mandatory attributeを無視してもよい。 The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. responderはCP(CFG_REQUEST)をinitiatorから受信しない場合はCP(CFG_REPLY)を送信しないこと。IRASによる不要なlookupが必要ないように。 In the case where the IRAS s configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the Child SA creation to fail. The initiator can fix this by later starting a new Configuration payload request. There is no associated data in the FAILED_CP_REQUIRED error. IRASの設定がCPがIDi IRACの IRASの設定がCPがIDiのために使用されるが、IRACがCP(CFG_REQUEST)を送信するのに失敗した場合、IRASは要求に失敗し、Child SAの作成をFAILED_CP_REQUIREDを送信して終了する。FAILED_CP_REQUIREDはIKE SAに影響はない。Child SAの作成は失敗する。initiatorは後ほど新しいConfiguration payload requestを開始することで問題を解決する。FAILED_CP_REQUIREDにはデータは含まれない。 2.20. Requesting the Peer s Version An IKE peer wishing to inquire about the other peer s IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE SA and first Child SA have been created. 対向peerのIKE SWバージョンを問い合わせる場合、IKEは下記の方法を使用してよい。IKE SAと最初のChild SAが作成された後にINFORMATIONAL exchangeで実施される例である。 Kaufman, et al. Standards Track [Page 55] RFC 5996 IKEv2bis September 2010 An IKE implementation MAY decline to give out version information prior to authentication or even after authentication in case some implementation is known to have some security weakness. In that case, it MUST either return an empty string or no CP payload if CP is not supported. IKEの実装では、実装にセキュリティの脆弱性があることがわかっている場合、バージョン情報を渡さなくてもよい。その場合、空の文字列を返すか、CPをサポートしていない場合はCP payloadを返さないこと。 Initiator Responder ------------------------------------------------------------------- HDR, SK{CP(CFG_REQUEST)} -- -- HDR, SK{CP(CFG_REPLY)} CP(CFG_REQUEST)= APPLICATION_VERSION( ) CP(CFG_REPLY) APPLICATION_VERSION( foobar v1.3beta, (c) Foo Bar Inc. ) 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (such as no matching cryptographic algorithms), the response contains a Notify payload indicating the error. The decision whether or not to send such a response depends whether or not there is an authenticated IKE SA. IKE処理中には様々な種類のエラーが発生する。一般的には不正な形式、許容できないpolicy（マッチするcryptographic algorithmがない等）の要求を受信した場合、応答としてerrorを示すNotify payloadで返す。応答を送信するか否かの判断はIKE SAが存在するかに依存する。 If there is an error parsing or processing a response packet, the general rule is to not send back any error message because responses should not generate new requests (and a new request would be the only way to send back an error message). Such errors in parsing or processing response packets should still cause the recipient to clean up the IKE state (for example, by sending a Delete for a bad SA). パーサーエラー、応答パケットの処理エラーがあった場合の一般的ルールは、応答により新しいrequestを生成しないため、エラーメッセージを応答しないことである。パーサーエラーや応答パケット処理エラーなどでは受信者がIKE状態をクリーンアップするべきである（例えばbad SAのためにDeleteを送信する。）。 Only authentication failures (AUTHENTICATION_FAILED and EAP failure) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a Delete payload. Other error conditions MAY require such an exchange if policy dictates that this is needed. If the exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED notification is not sent. 認証の失敗（AUTHENTICATION_FAILED and EAP failure）と不正なメッセージ形式（INVALID_SUNTAX）に限り、DELETE payloadを含むINFORMATIONAL exchange無しにIKE SAを削除する。その他のエラー条件によりpolicyで必要となった場合はexchangeが必要になる場合がある。exchangeがEAP Failureで終了する場合、AUTHENTICATION_FAILED notificationは送信されない。 2.21.1. Error Handling in IKE_SA_INIT Errors that occur before a cryptographically protected IKE SA is established need to be handled very carefully. There is a trade-off between wanting to help the peer to diagnose a problem and thus responding to the error and wanting to avoid being part of a DoS attack based on forged messages. 暗号で保護されたIKE SAが確立する前のエラーは注意して扱うべきである。peerの問題解析の手助けのための応答と、偽装メッセージによるDoS攻撃を防ぐことはトレードオフである。 Kaufman, et al. Standards Track [Page 56] RFC 5996 IKEv2bis September 2010 In an IKE_SA_INIT exchange, any error notification causes the exchange to fail. Note that some error notifications such as COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Because all error notifications are completely unauthenticated, the recipient should continue trying for some time before giving up. The recipient should not immediately act based on the error notification unless corrective actions are defined in this specification, such as for COOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSION. IKE_SA_INITでは様々なerror notificationによりexchangeが失敗する。 COOKIE、INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSIONなどのerror notificationは、以降のexchangeにより成功につながる可能しがあることに注意せよ。全てのerrorにおいて、認証は完了していないため、受信者はあきらめる前に何回かリトライしてよい。errorの受信者はしばらくリトライする。受信者はCOOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSIONのようにerror notification後の動作が規定されていない場合、即座にerror notificationに対する動作をしないこと。 2.21.2. Error Handling in IKE_AUTH All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, that peer needs to treat the information with caution. 何らかの理由（無効な共有秘密、invalid ID、証明書の失効/期限切れなど）により認証失敗が発生したIKE_AUTH exchangeでは、すべてのエラーにAUTHENTICATION_FAILED notificationが通知される。responder側でエラーが発生した場合、notificationは保護され、通常はpayloadのみを含む（データは含まない）。IKE_AUTH messageはencrypted/integrity protectedされているが、この通知を受信したpeerが対向のpeerをまだ認証していない場合、peerはその情報を慎重に処理する必要がある。 If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses. initiatorでエラーが発生した場合は、INFORMATIONAL exchangeで他のpayload無しで分けて返されることがある。これはresponseのエラー時に新しいexchangeを開始してはいけれないルールの例外である。 Note, however, that request messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as a response. The receiver should not verify the payloads related to authentication in this case. request messageがunsupported critical payloadを含んでいる場合または全体のメッセージフォーマットが壊れている場合は、そのメッセージ自体をrejectし、UNSUPPORTED_CRITICAL_PAYLOAD Notification、INVALID_SYNTAX Notificationをそれぞれ返す。メッセージの受信者は認証関連のpaylaodを検証しないこと。 If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established; however, establishing the Child SA or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, CERT, and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. IKE_AUTHで認証が成功するとIKE SAが確立される。ただし、Child SAの確立またはconfiguration informationの要求が失敗する場合がある。この場合は自動的にIKE SAが削除されることはない。responderはそのようなerror notificationの送信をIKE_AUTH（IDr, CERT, AUTH）にpyggybackしてよい（FAILED_CP_REQUIRED、NO_PROPOSAL_CHOSENなど）。initiatorはそれによって認証を失敗としないこと。initiatorはpolicyによっては後でそのようなIKE SAを削除してもよい。 Kaufman, et al. Standards Track [Page 57] RFC 5996 IKEv2bis September 2010 In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a Delete payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them, such as by using the Vendor ID payload. IKE_AUTH exchange or （IKE_AUTHのresponse処理でエラー応答で発生した場合）それの直後のINFORMATIONAL exchangeでNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notificationが発生した場合のみ、Delete payload無しにIKE SAが削除されるor作成されない。 2.21.3. Error Handling after IKE SA is Authenticated After the IKE SA is authenticated, all requests having errors MUST result in a response notifying about the error. IKE SAが認証された後、エラーが発生したrequestにはエラーに関する通知のresponseが返されること。 In normal situations, there should not be cases where a valid response from one peer results in an error situation in the other peer, so there should not be any reason for a peer to send error messages to the other end except as a response. Because sending such error messages as an INFORMATIONAL exchange might lead to further errors that could cause loops, such errors SHOULD NOT be sent. If errors are seen that indicate that the peers do not have the same state, it might be good to delete the IKE SA to clean up state and start over. 通常は有効な応答としてエラーを期待してはいけない。INFORMATIONAL exchangeのようなエラーメッセージを送信するとエラーのループが発生する可能性があり、そのようなメッセージを送らないこと。エラーがpeerが同じ状態でないことを示している場合、IKE SAをクリーンアップするために削除してもよい。 If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit Delete payload. requestをパースするpeerがフォーマット異常（MACのチェックとwindowのチェック完了後）を検出し、INVALID_SYNTAX notificationを応答した場合、これは両方のpeerで致命的な問題であることを意味し、IKE SAをDelete payload無しに削除する。 2.21.4. Error Handling Outside IKE SA A node needs to limit the rate at which it will send messages in response to unprotected messages. ノードは保護されていない応答の送信メッセージrateを制限する必要がある。 If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and the message is not a request to start an IKE SA), this may be the result of a recent crash of the node. If the message is marked as a response, the node can audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node can audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from where it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain an INVALID_IKE_SPI Notify payload. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. ノードがUDP port 500 or 4500でIKE SAのコンテキスト外(かつ、IKE SAの開始要求ではない)メッセージを受信した場合、これはノードのクラッシュの結果の可能性がある。メッセージが応答として認識される場合、ノードはそれをauditしてもよいが、応答してはいけない。メッセージが要求として認識される場合、ノードはそれをauditしてよく、応答してもよい。応答する場合、応答は同じIKE SPIとMessage IDでIPアドレスとポート宛に送信すること。応答は暗号化保護されず、INVALID_IKE_SPI Notify payloadを含むこと。INVALID_IKE_SPI notificationは認識できないIKEメッセージを宛先SPIで受信したことを示し、通常、受信者がリブートし、そのIKE SAを削除してしまったことを示す。 Kaufman, et al. Standards Track [Page 58] RFC 5996 IKEv2bis September 2010 A peer receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response that a genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a DoS attack. peerが保護されていないNotify payloadを受信した場合、応答せず、既存のSAの状態を変化させないこと。メッセージは偽造か応答メッセージが誤った可能性がある。ノードはそのようなメッセージ（ICMP destination unreachableなども）をSAの問題や、生存性チェック開始のためのヒントにするべきである。実装ではDoS攻撃にならないようにそのようなテストの頻度を制限すること。 If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. エラーがIKE requestのコンテキスト外（例：コンテキストがないSPIでESPメッセージを受信した場合）で発生した場合、ノードは問題内容のNotify payloadを含むINFORMATIONAL exchangeを開始すること。 A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. IKE SAのIPアドレス（およびNAT traversalの場合はport）から怪しいメッセージを受信したnodeはSAでIKE Notify payloadを含むIKE INFORMATIONAL exchangeを送信すること。受信者はSAの状態を変えないこと、誤動作を検出するauditを実施してよい。 2.22. IPComp Use of IP Compression [IP-COMP] can be negotiated as part of the setup of a Child SA. While IP Compression involves an extra header in each packet and a compression parameter index (CPI), the virtual compression association has no life outside the ESP or AH SA that contains it. Compression associations disappear when the corresponding ESP or AH SA goes away. It is not explicitly mentioned in any Delete payload. IP Compressionの使用はChild SAのsetupの一部としてネゴシエーションできる。IP Compressionは各パケットに追加のheaderとcompression parameter index(CPI)が必要になるが、仮想的な compression association はそれを含むESP/AH SAのライフタイムの範囲外である。対応するESP/AH SAがなくなった時、compression associationも消える。compression associationの削除は明示的にDelete paylaodでは指定されない。 Negotiation of IP Compression is separate from the negotiation of cryptographic parameters associated with a Child SA. A node requesting a Child SA MAY advertise its support for one or more compression algorithms through one or more Notify payloads of type IPCOMP_SUPPORTED. This Notify message may be included only in a message containing an SA payload negotiating a Child SA and indicates a willingness by its sender to use IPComp on this SA. The response MAY indicate acceptance of a single compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT occur in messages that do not contain SA payloads. IP CompressionのネゴシエーションはChild SAの暗号パラメータ関連のネゴシエーションとは別のものである。Child SAを要求するnodeは1つ以上のIPCOMP_SUPPORTED typeのNotify payloadにより、1つ以上のcompression algorithを通知してもよい。このNotify messageはChild SAをネゴシエーションするSA payloadを含むメッセージにだけ含まれ、そのSAでIPCompを使うことを送信者が希望することを示す。応答は、type IPCOMP_SUPPORTEDのNotify payloadで1つの許容するcompression algorithmを示す。これらのpayloadはSA payloadが含まれないメッセージでは発生しないこと。 The data associated with this Notify message includes a two-octet IPComp CPI followed by a one-octet Transform ID optionally followed by attributes whose length and format are defined by that Transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. このNotify messageに関連付けられるデータは、2 octet のIPComp CPI、1 octetのTransform ID、オプションでTransform IDで定義されるattribute（length/format）を含んでいる。SAを提案するmessageは複数のアルゴリズムを示すため、複数のIPCOMP_SUPPORTED notificationを含んでよい。SAを許容するメッセージでは1つだけを含む。 Kaufman, et al. Standards Track [Page 59] RFC 5996 IKEv2bis September 2010 The Transform IDs are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform IDは下記に記載される。この値はRFC 4306発行時のものである。その他の値がその後追加されてもよい。[IKEV2IANA]の最新バージョンを参照せよ。 Name Number Defined In ------------------------------------- IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051 Although there has been discussion of allowing multiple compression algorithms to be accepted and to have different compression algorithms available for the two directions of a Child SA, implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and MUST NOT compress using an algorithm other than one proposed and accepted in the setup of the Child SA. 複数のcompression algorithmを受け入れ、Child SAの2つの方向に異なるalgorithmを使用する議論がされいているが、この仕様の実装では提案されなかったIPComp algorithmを受け入れてはいけず、1つ以上を受け入れてはいけず、Child SAのsetup時に受け入れた1つのalgorithm以外を使用しないこと。 A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose multiple cryptographic suites and propose IP Compression with some of them but not others. IPCompを暗号化パラメータのネゴシエーションと分離する副作用は、複数の暗号化suiteを提案し、IP Compressionをいくつかでは適用するが他では適用しないということができないことである。 In some cases, Robust Header Compression (ROHC) may be more appropriate than IP Compression. [ROHCV2] defines the use of ROHC with IKEv2 and IPsec. ケースによっては、Robust HEader Compression(ROHC)がIP Compressionより役に立つだろう。[ROHCV2]ではIKEv2とIPsecでのROCHの使用方法を定義している。 2.23. NAT Traversal Network Address Translation (NAT) gateways are a controversial subject. This section briefly describes what they are and how they are likely to act on IKE traffic. Many people believe that NATs are evil and that we should not design our protocols so as to make them work better. IKEv2 does specify some unintuitive processing rules in order that NATs are more likely to work. Network Address Translation(NAT) gatewayは議論すべき話題である。この章ではこれら(NAT gateway)がどのようにIKE trafficに影響するかを説明する。多くの人はNATはよいものではないので、NATを動作させるためにprotocolを設計するべきではないと信じている。IKEv2はNATが動作するようにいくつかの直感的ではない処理を規定している。 NATs exist primarily because of the shortage of IPv4 addresses, though there are other rationales. IP nodes that are behind a NAT have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT but that are likely to be reused by nodes behind other NATs. Generally, nodes behind NATs can communicate with other nodes behind the same NAT and with nodes with globally unique addresses, but not with nodes behind other NATs. There are exceptions to that rule. When those nodes make connections to nodes on the real Internet, the NAT gateway translates the IP source address to an address that will be routed back to the gateway. Messages to the gateway from the Internet have their destination addresses translated to the internal address that will route the packet to the correct endnode. 他の理由もあるが、NATはIPv4の不足により存在する。NAT配下のIP nodeはグローバル一意でないIPアドレスを持ち、そのアドレスはNAT配下では一意であり、しかしそのアドレスは他のNAT配下のノードで再利用される可能性がある。一般的には、NAT配下のnodeは同じNAT配下の他のnode、グローバル一意なアドレスのnodeと通信ができるが、他のNAT配下のnodeとは通信はできない。このルールには例外がある。これらのnodeがinternet上のnodeと通信をすると、NAT gatewayはsource IP addressをgatewayにルーティングされるアドレスに変換する。internetからgatewayへのメッセージはdestination addressを正しいendnodeへの内部アドレスを変換する。 NATs are designed to be transparent to endnodes. Neither software on the node behind the NAT nor the node on the Internet requires modification to communicate through the NAT. Achieving this transparency is more difficult with some protocols than with others. Protocols that include IP addresses of the endpoints within the payloads of the packet will fail unless the NAT gateway understands the protocol and modifies the internal references as well as those in the headers. Such knowledge is inherently unreliable, is a network layer violation, and often results in subtle problems. NATはendnodeに対して透過であるように設計されている。NAT配下のnodeのsoftwareかInternet上のnodeのどちらかはNATを介して通信するように変更する必要がある。この透過を実現することは、プロトコルによっては難しい。packetのpaylaodの中にendpointのIP addressを含むprotocolでは、NAT gatewayがprotocolを解釈してheaderと同様に内部情報を変更しないと問題が起こる。そのような情報を得ることは、信頼できず、ネットワーク層の違反であり、難しい問題である。 Opening an IPsec connection through a NAT introduces special problems. If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected. Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature. For that reason, IKEv2 will use UDP encapsulation of IKE and ESP packets. This encoding is slightly less efficient but is easier for NATs to process. In addition, firewalls may be configured to pass UDP-encapsulated IPsec traffic but not plain, unencapsulated ESP/AH or vice versa. NATを通してIPsecをする場合の特殊な問題を紹介する。接続がtransport modeの場合、packetのIP addressの変更は、checksum NGになり、NATはcryptographically protectされているため、正しいchecksumに修正することができない。tunnel modeであっても、NATに透過的にAH/ESPのアドレスを変換する特殊なロジックが必要になり、そのロジックは信頼性がないなどするためルーティングで問題になる。そのため、IKEv2ではIKE/ESP packetにUDP encapsulationを使用する。このencodingは非効率的だが、NATの処理よりは簡単である。それに加え、fairewallはUDP-encapsulated IPsec trafficをESP/AHのように透過させるように設定することができる。 It is a common practice of NATs to translate TCP and UDP port numbers as well as addresses and use the port numbers of inbound packets to decide which internal node should get a given packet. For this reason, even though IKE packets MUST be sent to and from UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. This is because the ports may be modified as the packets pass through NATs. Similarly, IP addresses of the IKE endpoints are generally not included in the IKE payloads because the payloads are cryptographically protected and could not be transparently modified by NATs. TCP/UDP port番号だけでなく、アドレスを変換し、内部nodeを決定するために受信パケットのport番号を使用するのはNATの一般的な手法である。そのため、IKE packetはUDP port 500か4500で送信されなければならないが、NATではあらゆるポートから受け取り、受信したポートに応答する必要がある。これは、packetがNATを通過させるためポートが変更されてもよいからである。同様に、payloadは暗号化保護されており、NATでは書き換えできないため、IKE endpointのIPアドレスはIKE payloadに含まれていない。 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec endpoint that discovers a NAT between it and its correspondent (as described below) MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). Port4500はUDPカプセル化ESP/IKEのために予約されている。NATを発見したIPsec endpointはport 4500または500からのパケットを送受信する。 An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP-encapsulated ESP packets is required. UDP encapsulation MUST NOT be done on port 500. If Network Address Translation Traversal (NAT-T) is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP-encapsulated ESP and non-UDP-encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP. IKEを開始するときinitiatorはIKE/ESPのためにNATの有無に関わらずport 4500を使用してよい。両方がport 4500を使用していて、ESP送信にUDPカプセル化を必要としない場合でもUDPカプセル化受信時に理解できることが必要である。UDPカプセル化はport 500では使用しないこと。NATはサポートされると（IKE_SA_INITでNAT_DETECTION_*_IP payloadが交換された場合）、すべてのデバイスは任意のタイミングでUDPカプセル化/UDP非カプセル化のESPパケットを受信し、処理できること。どちらがESPでUDPカプセル化をしたかに関わらず、どちら側もUDPカプセル化を使用してよい。しかし、NATを検知した場合は両方ともESPのためにUDPカプセル化を使用すること。 The specific requirements for supporting NAT traversal [NATREQ] are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal. NAT traversalをサポートするための仕様要求は下記のとおり[NATREQ]。NAT traversalのサポートはオプションである。この章に限り、要求はNAT traversalをサポートする実装にのみ適用される。 o Both the IKE initiator and responder MUST include in their IKE_SA_INIT packets Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect if there is NAT between the hosts, and which end is behind the NAT. The location of the payloads in the IKE_SA_INIT packets is just after the Ni and Nr payloads (before the optional CERTREQ payload). IKEのinitiator/responderはIKE_SA_INITのNotofy payloadにNAT_DETECTION_SOURCE_IP、NAT_DETECTION_DESTINATION_IPを含めること。これらのpayloadはhost間にNATがあり、endがNAT配下にあることを検出したときに使用される。payloadの場所はIKE_SA_INITのNi/Nr payloadの後ろでOptionのCERTREQ paylaodの前である。 o The data associated with the NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port from which this packet was sent. There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a message if the sender does not know which of several network attachments will be used to send the packet. NAT_DETECTION_SOURCE_IP notificationに関連付けられるデータはそのパケットのSPI（headerの順）、IP address、portの各SHA-1 digestである。送信者がどのネットワークを使用してパケットを送信されるか知らない場合、複数のNAT_DETECTION_SOURCE_IP payloadがあってもよい。 o The data associated with the NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port to which this packet was sent. NAT_DETECTION_DESTINATION_IP notificationに関連付けれられるデータはそのパケットのSPI（headerの順）、IP address、portの各SHA-1 digestである。 o The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source or recipient IP address (respectively), address, and port, and if they don t match, it SHOULD enable NAT traversal. In the case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported. In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that the system receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT and that system SHOULD start sending keepalive packets as defined in [UDPENCAPS]; alternately, it MAY reject the connection attempt if NAT traversal is not supported. NAT_DETECTION_SOURCE_IPまたはNAT_DETECTION_DESTINATION_IP notificationのどちらかの受信者はSHA-1 hash of the SPIs, source or recipient IP addressを比較し、それらが一致しない場合はNAT traversalを有効にする必要がある。NAT traversalをサポートしていない場合にNAT_DETECTION_SOURCE_IP payloadの全てのNAT_DETECTION_SOURCE_IP hashが不一致の場合、受信者は接続を拒絶してもよい。 Kaufman, et al. Standards Track [Page 62] RFC 5996 IKEv2bis September 2010 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches the expected value of the source IP and port found from the IP header of the packet containing the payload, it means that the system sending those payloads is behind a NAT (i.e., someone along the route changed the source address of the original packet to match the address of the NAT box). In this case, the system receiving the payloads should allow dynamic updates of the other systems IP address, as described later. NAT_DETECTION_SOURCE_IP payload(s)を受信し、期待するsource IP、portがpayloadのIP headerと不一致の場合、そのpayloadを送信したsystemはNAT配下にある（すなわち、ルーティングのため、NAT boxのアドレスに一致されるため、元のパケットのsource addressを変更する。）。この場合、payloadを受信したsystemは他のsystemのIP addressの動的な更新を許容する必要がある。 o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP payloads if present, and if they do not match the addresses in the outer packet, MUST tunnel all future IKE and ESP packets associated with this IKE SA over UDP port 4500. IKE initiatorはNAT_DETECTION_SOURCE_IP、NAT_DETECTION_DESTINATION_IPが存在した場合は確認すること。また、Outer packetのアドレスと一致しなかった場合、IKE SAに関連付けられるIKE/ESP packetをUDP port 4500でトンネリングする。 o To tunnel IKE packets over UDP port 4500, the IKE header has four octets of zero prepended and the result immediately follows the UDP header. To tunnel ESP packets over UDP port 4500, the ESP header immediately follows the UDP header. Since the first four octets of the ESP header contain the SPI, and the SPI cannot validly be zero, it is always possible to distinguish ESP and IKE messages. UDP port 4500でIKE packetをトンネルするために、IKE headerは4 octetの0 paddingがあり、その後、UDP headerが続く。UDP port 4500でESP packetをトンネルするために、ESP headerの後にUDP headerが続く。ESP headerの最初の4 octetはSPIで、SPIは0にすることはできないため、常にESP messageとIKE messageを区別できる。 o Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected. 実装は、NATを検出していなかった場合でもUDPカプセル化ESPを処理すること。 o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the Traffic Selectors associated with the exchange. In the case of transport mode NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. This is covered in greater detail in Section 2.23.1. Transport modeのTCP、UDP packetのチェックサム計算([UDPENCAPS])に必要な元のsource/destication IP addressはexchangeによるTraffic Selectorから得られる。Transport modeのNAT traversalでは、Traffic Selectorは元のIP addressとして1つだけ含まれていること。これはSection 2.23.1に詳細が書かれている。 o There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). This will be apparent to a host if it receives a packet whose integrity protection validates, but has a different port, address, or both from the one that was associated with the SA in the validated packet. When such a validated packet is found, a host that does not support other methods of recovery such as IKEv2 Mobility and Multihoming (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all packets (including retransmission packets) to the IP address and port in the validated packet, and SHOULD store this as the new address and port combination for the SA (that is, they SHOULD dynamically update the address). A host behind a NAT SHOULD NOT do this type of dynamic address update if a validated packet has different port and/or address values because it opens a possible DoS attack (such as allowing an attacker to break the connection with a single packet). Also, dynamic address update should only be done in response to a new packet; otherwise, an attacker can revert the addresses with old replayed packets. Because of this, dynamic updates can only be done safely if replay protection is enabled. When IKEv2 is used with MOBIKE, dynamically updating the addresses described above interferes with MOBIKE s way of recovering from the same situation. See Section 3.8 of [MOBIKE] for more information. NAT boxがまだ使用中のマッピングリストを削除する場合がある（例えば、keepalive intervalが長すぎる場合（無通信だがkeepしている場合。）やNAT boxがリブートした場合）。integrity protection検証をするパケットを受信したが、異なるportまたはaddressがSAの検証パケットに設定されている場合、これはhostにとって明らかである。このような検証パケットが検出されると、IKEv2 MobilityとMultihoming(MOBIKE)のようなリカバリー方法をサポートしておらず、NAT配下にないhostは、すべてのパケット(再送パケットを含む)をそのIP addressに送信し、SAのために新しいaddressとportの組み合わせを保存すること（つまり、addressを動的に更新すること）。NAT配下のhostは異なるport/addressの検証パケットの場合に動的アドレス更新をしないこと。それは、DoS攻撃になるためである（攻撃者は1パケットでコネクションを切断することができる。）。また、動的アドレス更新は新しいパケットの応答としてのみ実行されること。そうでないと、攻撃者は古い再送パケットでアドレスを戻すことができる。再送保護(replay protection)が有効な場合、動的アドレス更新を安全に行うことができる。IKEv2でMOBIKEを使用する場合、動的アドレス更新は、同じような状況からの復旧とMOBIKEに干渉する。詳細はSection 3.8の[MOBIKE]参照。 2.23.1. Transport Mode NAT Traversal Transport mode used with NAT Traversal requires special handling of the Traffic Selectors used in the IKEv2. The complete scenario looks like NAT Traversalで使用されるTransport modeは、IKEv2で使用されるTraffic Selectorの特別な処理を必要とする。完全なシナリオは下記のようになる。 +------+ +------+ +------+ +------+ |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |node | ------ | A | ---------- | B | ------- | | +------+ +------+ +------+ +------+ (Other scenarios are simplifications of this complex case, so this discussion uses the complete scenario.) 他のシナリオはこのシナリオを単純化したケースなので、この完全なシナリオで議論する。 In this scenario, there are two address translating NATs NAT A and NAT B. NAT A is a dynamic NAT that maps the client s source address IP1 to IPN1. NAT B is a static NAT configured so that connections coming to IPN2 address are mapped to the gateway s address IP2, that is, IPN2 destination address is mapped to IP2. This allows the client to connect to a server by connecting to the IPN2. NAT B does not necessarily need to be a static NAT, but the client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, that is, the IPN2 address. If NAT B is a static NAT, then its address can be configured to the client s configuration. Another option would be to find it using some other protocol (like DNS), but that is outside of scope of IKEv2. このシナリオでは、2つの、アドレス変換をするNATがある。NAT AとNAT Bである。 NAT Aはクライアントのsource address IP1をIPN1にマッピングする動的NAT(dynamic NAT)である。 NAT Bは静的NAT(static NAT)で、IPN2への通信をgatewayのaddress IP2にマッピングする。つまり、destination addressのIPN2をIP2にマッピングする。これは、クライアントがIPN2に接続することでserverに接続できることを可能にする。NAT Bは必ずしも静的NATである必要はないが、クライアントはserverに接続する方法を知っている必要があり、NAT BのアドレスIPN2 addressを知っていればよい。NAT Bが静的NATである場合、アドレスはクライアントの設定で設定することができる。その他のオプションとして、そのアドレスを他のプロトコル(DNSなど)を使用して発見することもできるが、IKEv2のスコープ外である。 In this scenario, both the client and server are configured to use transport mode for the traffic originating from the client node and destined to the server. このシナリオでは、クライアントとサーバーともに、クライアントから発信され、サーバー宛のトラフィックにtransport modeが設定される。 When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it may have a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its Peer Authorization Database (PAD) and SPD needs to have a configuration matching those addresses (or wildcard entries covering them). クライアントからサーバーにトラフィックを送信するIKEv2 SAとChild SAの作成を開始するときは、source IP address IP1、destination IP address IPN2をパケットがもつ。Peer Authorization Database(PAD)とSPDはこれらのアドレスにマッチングする設定（またはそれらをカバーするワイルドカード設定）を持っている必要がある。 Kaufman, et al. Standards Track [Page 64] RFC 5996 IKEv2bis September 2010 Because this is transport mode, it uses exactly same addresses as the Traffic Selectors and outer IP address of the IKE packets. For transport mode, it MUST use exactly one IP address in the TSi and TSr payloads. It can have multiple Traffic Selectors if it has, for example, multiple port ranges that it wants to negotiate, but all TSi entries must use the IP1-IP1 range as the IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP addresses. The first Traffic Selector of TSi and TSr SHOULD have very specific Traffic Selectors including protocol and port numbers, such as from the packet triggering the request. Transport modeのため、Traffic SelectorのaddressとIKE packetのouter IP addressは同じアドレスを使用する。Transport modeでは、TSi/TSr payloadに1つだけあるアドレスを使用する。複数のTraffic Selectorがあり、複数のportがネゴシエーションされる場合、TSiはIP1-IP1の範囲（IP1のみ）がIPアドレスとしてあり、TSrはIPN2-IPN2の範囲（IPN2のみ）がIPアドレスとしてある必要がある。このようなリクエストpacketをトリガにした場合、特殊なTraffic Selectorをもつ。 NAT A will then replace the source address of the IKE packet from IP1 to IPN1, and NAT B will replace the destination address of the IKE packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same Traffic Selectors that were sent by the client, but the IP address of the IKE packet has been replaced by IPN1 and IP2. NAT AはIKE packetのsource addressをIP1からIPN1に置き換える。NAT BはIKE packetのdestination addressをIPN2からIP2に置き換える。そのため、パケットがserverに届いたとき、クライアントから送信されたのと同じTraffic Selectorを持っているが、IKE packetのIP addressはIPN1とIP2に置き換えられている。 When the server receives this packet, it normally looks in the Peer Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based on the ID and then searches the SPD based on the Traffic Selectors. Because IP1 does not really mean anything to the server (it is the address client has behind the NAT), it is useless to do a lookup based on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry. サーバーがこのパケットを受信すると、通常どおり、IDに基づいてRFC 4301[IPSECARCH]のPeer Authorization Database(PAD)で検索し、Traffic Selectorに基いてSPDを検索する。IP1はサーバーにとって意味のないアドレスのため（NAT配下のクライアントが持っているアドレスのため）、Transport modeの場合はそのアドレスに基いて検索することは意味が無い。一方、SPD entryでマッチングを見つける前に、サーバーはそのポリシーでTransport modeが許可されているか知ることができない。 In this case, the server should first check that the initiator requested transport mode, and then do address substitution on the Traffic Selectors. It needs to first store the old Traffic Selector IP addresses to be used later for the incremental checksum fixup (the IP address in the TSi can be stored as the original source address and the IP address in the TSr can be stored as the original destination address). After that, if the other end was detected as being behind a NAT, the server replaces the IP address in TSi payloads with the IP address obtained from the source address of the IKE packet received (that is, it replaces IP1 in TSi with IPN1). If the server s end was detected to be behind NAT, it replaces the IP address in the TSr payloads with the IP address obtained from the destination address of the IKE packet received (that is, it replaces IPN2 in TSr with IP2). この場合、serverは始めにinitiaotrがtransport modeであるか確認し、Traffic Selectorのアドレスを置換する必要がある。古いTraffic Selector IPはチェックサムを後で計算するために保存する必要がある（元のsource addressとして記憶されるTSiのIP addressと元のdestination addressとして記憶されるTSrがある）。そして、対向がNAT配下にあることが検出された場合、サーバーは受信したIKE packetのsource addressから取得したIP addressをTSi payloadのIP addressで置換する（つまり、IPN1をTSiのIP1で置換する）。サーバー側がNAT配下にあることを検出した場合、受信したIKE packetのdestination addressから取得したIP addressをTSr payloadのIP addressで置換する（つまりTSrのIPN2をIP2に置換する）。 After this address substitution, both the Traffic Selectors and the IKE UDP source/destination addresses look the same, and the server does SPD lookup based on those new Traffic Selectors. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original Traffic Selectors. If the second lookup succeeds, the server will create an SA in tunnel mode using real Traffic Selectors sent by the other end. アドレス置換の後、Traffic SelectorとIKE UDP source/destination addressは同じに見え、serverは新しいTraffic SelectorをもとにSPDの検索をする。エントリが見つかり、それがTransport modeを許可する場合、そのエントリが使用される。エントリが見つかったが、transport modeが許可されていない場合、serverはアドレス置換を基に戻し、元のTraffic SelectorでSPDの検索をやり直してよい。2回目の検索で成功した場合、serverは対向から送信されたTraffic Selectorを使用してtunnel modeでSAを作成する。 This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This also will make sure the Security Association Database (SAD) entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack. SPDはlocal hostが認識するaddressで検索されるため、このアドレス置換はtransport modeで必要である。また、Security Association Database(SAD)を作成し、localアドレスを設定したパケットを応答する。 The most common case is that the server s SPD will contain wildcard entries matching any addresses, but this also allows making different SPD entries, for example, for different known NATs outer addresses. 最も一般的なケースは、サーバーのSPDがどのアドレスにもマッチするワイルドカードを含むが（例えば、既知の異なるNATのouter addressのため）異なるSPDエントリーの作成は許容される。 After the SPD lookup, the server will do Traffic Selector narrowing based on the SPD entry it found. It will again use the already substituted Traffic Selectors, and it will thus send back Traffic Selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the Traffic Selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2. SPDの検索の後、サーバーはSPDエントリに基いてTraffic Selectorを狭める。これは、既に置換したTraffic Selectorを使用し、IPN1とIP2をもつTraffic Selectorとして送り返す。さらにTraffic Selectorが使用するprotocol number、port rangeも狭めることができる。serverからはChild SAのためのSADエントリはIPN1とIP2をもつことになる。 When the client receives the server s response to the Child SA, it will do similar processing. If the transport mode SA was created, the client can store the original returned Traffic Selectors as original source and destination addresses. It will replace the IP addresses in the Traffic Selectors with the ones from the IP header of the IKE packet it will replace IPN1 with IP1 and IP2 with IPN2. Then, it will use those Traffic Selectors when verifying the SA against sent Traffic Selectors, and when installing the SAD entry. クライアントはChild SAへのサーバーの応答を受信すると同様の処理をする。Transport modeのSAが作成されている場合、クライアントは元の返信されたsource/destination addressとして元のTraffic Selectorを保存する。IKE packetのIP headerからTraffic SelectorのIP addressに置換される。IPN1をIP1、IP2をIPN2に置換される。送信したTraffic Selectorに対するSAの検証するとき、SADエントリーを作成するときにTraffic Selectorを使用する。 A summary of the rules for NAT traversal in transport mode is Transport modeにおけるNAT traversalのルールのサマリは下記の通り、 For the client proposing transport mode クライアントがtransport modeを提案した場合、 - The TSi entries MUST have exactly one IP address, and that MUST match the source address of the IKE SA. TSiは厳密に1つだけIPアドレスを持ち、それはIKE SAのsource addressと一致すること。 - The TSr entries MUST have exactly one IP address, and that MUST match the destination address of the IKE SA. TSrは厳密に1つだけIPアドレスを持ち、それはIKE SAのdestination addressと一致すること。 - The first TSi and TSr Traffic Selectors SHOULD have very specific Traffic Selectors including protocol and port numbers, such as from the packet triggering the request. 最初のTSi/TSr Traffic Selectorは、リクエストのパケットのport/protocl 番号をもつ。 - There MAY be multiple TSi and TSr entries. 複数のTSi/TSrエントリがあってもよい。 Kaufman, et al. Standards Track [Page 66] RFC 5996 IKEv2bis September 2010 - If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its response) SAにtransport modeが選択された場合。（すなわち、サーバーがUSE_TRANSPORT_MODE notificationを応答した場合） - Store the original Traffic Selectors as the received source and destination address. 受信したsource/destination addressとして元のTraffic Selectorを保存する。 - If the server is behind a NAT, substitute the IP address in the TSr entries with the remote address of the IKE SA. サーバーがNAT配下にある場合、IKE SAのremote addressでTSrエントリのIPアドレスを置き換える。 - If the client is behind a NAT, substitute the IP address in the TSi entries with the local address of the IKE SA. clidentがNAT配下にある場合、IKE SAのlocal addressでTSiエントリのIPアドレスを置き換える。 - Do address substitution before using those Traffic Selectors for anything other than storing original content of them. This includes verification that Traffic Selectors were narrowed correctly by the other end, creation of the SAD entry, and so on. 元の内容を保存する以外には、Traffic Selectorを使う前にaddressの置換をする。これには、Traffic Selectorが対向から狭められたことの確認、SADエントリの作成が含まれる。 For the responder, when transport mode is proposed by client クライアントがtransport modeを提案した場合、responderは、 - Store the original Traffic Selector IP addresses as received source and destination address, in case undo address substitution is needed, to use as the real source and destination address specified by [UDPENCAPS], and for TCP/UDP checksum fixup. [UDPENCAPS]の「real source and destination address」として使用するためとTCP/UDP checksumの計算のために、置換されたIP addressを戻す必要がある場合のために受信したsource/destination addressとして、元のTraffic Selector IP addressを保存する。 - If the client is behind a NAT, substitute the IP address in the TSi entries with the remote address of the IKE SA. clidentがNAT配下にある場合、IKE SAのremote addressでTSiエントリのIPアドレスを置き換える。 - If the server is behind a NAT, substitute the IP address in the TSr entries with the local address of the IKE SA. サーバーがNAT配下にある場合、IKE SAのlocal addressでTSrエントリのIPアドレスを置き換える。 - Do PAD and SPD lookup using the ID and substituted Traffic Selectors. IDを使用したPAD/SPDの検索とTraffic Selectorの置換をする。 - If no SPD entry was found, or if found SPD entry does not allow transport mode, undo the Traffic Selector substitutions. Do PAD and SPD lookup again using the ID and original Traffic Selectors, but also searching for tunnel mode SPD entry (that is, fall back to tunnel mode). SPDエントリが見つからない場合か、SDPエントリがtransport modeを許容していない場合、Traffic Selectorの置換を基に戻す。IDと元のTraffic SelectorによるPAD/SPDの検索、tunnel modeのSPDエントリを検索をする。すなわち、tunnel modeでのフォールバックをする。 - However, if a transport mode SPD entry was found, do normal traffic selection narrowing based on the substituted Traffic Selectors and SPD entry. Use the resulting Traffic Selectors when creating SAD entries, and when sending Traffic Selectors back to the client. transport modeのSPDエントリが見つかった場合、置換したTraffic SelectorとSPDエントリに基いてTraffic Selectionを狭める。SADエントリを作成し、clientにTraffic Selectorを送信するときは、その結果のTraffic Selectorを使用する。 Kaufman, et al. Standards Track [Page 67] RFC 5996 IKEv2bis September 2010 2.24. Explicit Congestion Notification (ECN) When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see [ECN]). IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel mode Child SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel mode SAs created by IKEv2 MUST support the ECN full- functionality option for tunnels specified in [ECN] and MUST implement the tunnel encapsulation and decapsulation processing specified in [IPSECARCH] to prevent discarding of ECN congestion indications. IPsec tunnelが[IPSECARCH-OLD]で規定される動作をする場合、tunnel 非カプセル化処理はECNの輻輳通知を破棄するため、ECNを使用することはOuter IP headerには適していない。IKEv1ベースのIPsecのためのIPsec tunnelへのECNは、複数のoperation modeとnegotiationが必要である[ECN]。IKEv2では、ECNがIKEv2で作成される全てのtunnel mode Child SAのOuter IP headerで使用可能とすることで簡略化してある。具体的には、IKEv2で作成される全てのtunnel mode SAのtunnel カプセル化/非カプセル化では、[ECN]で規定されたECN full-functionality optionをサポートし、ECNの輻輳通知の廃棄を防ぐため、[IPSECARCH]で規定されたtuunel カプセル化/非カプセル化の処理を実装すること。 2.25. Exchange Collisions Because IKEv2 exchanges can be initiated by either peer, it is possible that two exchanges affecting the same SA partly overlap. This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request that it cannot process in a normal fashion. IKEv2 exchangeはどちらのpeerからも開始できるので、同じSAに影響する2 exchangeが競合する可能性がある。これは、一時的なSAの同期状態が不一致が引き起こされ、peerは通常の方法で処理できないrequestを受信する可能性がある。 Obviously, using a window size greater than 1 leads to more complex situations, especially if requests are processed out of order. This section concentrates on problems that can arise even with a window size of 1, and recommends solutions. window sizeが1より大きい要求が順序通り処理されないとき問題はより複雑になる。このSectionではwindow size 1のときの推奨される解決方法について述べる。 A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives a request that cannot be completed due to a temporary condition such as a rekeying operation. When a peer receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation; it MUST wait so that the sender may complete whatever operation caused the temporary condition. The recipient MAY retry the request one or more times over a period of several minutes. If a peer continues to receive TEMPORARY_FAILURE on the same IKE SA after several minutes, it SHOULD conclude that the state information is out of sync and close the IKE SA. peerがrekeyのような一時的な状態のため、完了できないrequestを受信した場合、TEMPORARY_FAILURE notificationを送信すること。peerがTEMPORARY_FAILURE notificationを受信した場合、operationを即座にリトライしないこと。送信者の操作が完了できるように待つこと。受信者はrequestを数分後に何度かリトライしてよい。peerが数分後に同じIEK SA上でTEMPORARY_FAILUREを受信し続けた場合、状態がsyncしていないということでIKE SAを削除すること。 A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify payload, which is copied from the SPI field in the REKEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA (if it still exists) and send a request to create a new Child SA from scratch (if the Child SA does not yet exist). peerが存在しないChild SAへのrekey requestを受信したときにCHILD_SA_NOT_FOUND notificationを送信すること。initiatorがrekeyを試行したSAは、REKEY_SA notificationのSPI fieldからコピーし、Notify payloadのSPI fieldで示される。peerがCHILD_SA_NOT_FOUND notificationを受信した場合、即座にそのChild SA（また存在する場合）を削除し、新しいChild SAを新規に作成するrequestを送信する（まだChild SAができていなかったら）。 Kaufman, et al. Standards Track [Page 68] RFC 5996 IKEv2bis September 2010 2.25.1. Collisions while Rekeying or Closing Child SAs If a peer receives a request to rekey a Child SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to rekey a Child SA that it is currently rekeying, it SHOULD reply as usual, and SHOULD prepare to close redundant SAs later based on the nonces (see Section 2.8.1). If a peer receives a request to rekey a Child SA that does not exist, it SHOULD reply with CHILD_SA_NOT_FOUND. peerは閉じようとしてるChild SAのrekey requestを受信した場合、TEMPORARY_FAILUREを応答すること。 peerはrekeyしているChild SAのrekey requestを受信した場合、正常に応答し、Section 2.8.1のnoncesに従って重複したSAを削除すること。存在しないChild SAへのrekey requestを受信したpeerはCHILD_SA_NOT_FOUNDを応答すること。 If a peer receives a request to close a Child SA that it is currently trying to close, it SHOULD reply without a Delete payload (see Section 1.4.1). If a peer receives a request to close a Child SA that it is currently rekeying, it SHOULD reply as usual, with a Delete payload. If a peer receives a request to close a Child SA that does not exist, it SHOULD reply without a Delete payload. peerは閉じようとしているChild SAのclose requestを受信した場合、Delete payload無しに応答すること（Section 1.4.1参照）。peerはrekayしているChild SAのclose requestを受信した場合、Delete payloadで応答すること。peerが存在しないChild SAのclose requestを受信した場合、Delete payload無しに応答すること。 If a peer receives a request to rekey the IKE SA, and it is currently creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD reply with TEMPORARY_FAILURE. peerがIKE SAをrekeyする要求を受信したとき、そのIKE SAのChild SAがcreating/rekeying/closingしている場合、TEMPORARY_FAILUREを応答すること。 2.25.2. Collisions while Rekeying or Closing IKE SAs If a peer receives a request to rekey an IKE SA that it is currently rekeying, it SHOULD reply as usual, and SHOULD prepare to close redundant SAs and move inherited Child SAs later based on the nonces (see Section 2.8.2). If a peer receives a request to rekey an IKE SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE. peerがrekey中のIKE SAのrekey requestを受信した場合、通常通り応答し、nonceに基づき重複SAを削除し、Child SAを移動すること（Section 2.8.2参照）。peerが削除中のIKE SAのrekey requestを受信した場合、TEMPORARY_FAILUREを応答すること。 If a peer receives a request to close an IKE SA that it is currently rekeying, it SHOULD reply as usual, and forget about its own rekeying request. If a peer receives a request to close an IKE SA that it is currently trying to close, it SHOULD reply as usual, and forget about its own close request. peerがrekey中のIKE SAのclose requestを受信した場合、通常通り応答しrekey requestは忘れること。peerがclose中のIKE SAのclose requestを受信した場合、通常通り応答し自身のclose requestは忘れること。 If a peer receives a request to create or rekey a Child SA when it is currently rekeying the IKE SA, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA when it is currently rekeying the IKE SA, it SHOULD reply as usual, with a Delete payload. peerはrekey中のIKE SAでChild SAのcreate or rekeyのrequestを受信した場合、TEMPORARY_FAILUREを応答すること。peerがrekay中のIKE SAでChild SAのdeleteを受信した場合、通常通りDelete payloadで応答すること。 3. Header and Payload Formats In the tables in this section, some cryptographic primitives and configuration attributes are marked as UNSPECIFIED . These are items for which there are no known specifications and therefore interoperability is currently impossible. A future specification may describe their use, but until such specification is made, implementations SHOULD NOT attempt to use items marked as UNSPECIFIED in implementations that are meant to be interoperable. このSectionの表ではいくつかの暗号プリミティブとconfiguration attributeは UNSPECIFIED になっている。既存の仕様書にない項目なので相互運用は不可能である。今後の仕様ではそれらを使用してよいが、相互運用可能な実装では UNSPECIFIED の項目は使用しないこと。 3.1. The IKE Header IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zeros are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. Each IKE message begins with the IKE header, denoted HDR in this document. Following the header are one or more IKE payloads each identified by a Next Payload field in the preceding payload. Payloads are identified in the order in which they appear in an IKE message by looking in the Next Payload field in the IKE header, and subsequently according to the Next Payload field in the IKE payload itself until a Next Payload field of zero indicates that no payloads follow. If a payload of type Encrypted is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet and an Encrypted payload MUST NOT contain another Encrypted payload. IKEメッセージはport 500/4500でUDP datagramで送信する。UDPヘッダの情報は、IPアドレスとUDP portが応答パケットに使用されることを除けば無視される。UDP port 500で送信する場合、IKEメッセージはUDPヘッダの直後に設定される。UDP port 4500で送信する場合、IKEメッセージはUDPヘッダの後の4オクテットの0の後に開始する。この0はIKEメッセージの一部ではないので、IKEのlength、checksumには含まれない。すべてのIKEメッセージはIKE headerで始まる。略記はHDR。ヘッダの後には1つ以上の、 Next Payload filedで示されるIKE payloadがある。さらに次のpayloadがある場合は、そのpayloadの Next Payload filedで示され、 Next Payload filedが0の場合は次のPayloadがないことを示す。Encrypted payloadは解読され、追加のpayloadとして解析される。Encrypted paylaodは最後のpayloadであり、Encrypted payloadはEncrypted payloadを含まないこと。 The responder s SPI in the header identifies an instance of an IKE Security Association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers, including multiple sessions per peer. ヘッダー内のresponder SPIはIKE Security Accosicationを識別する。これにより、peer毎にセッションを多重化することができる。 All multi-octet fields representing integers are laid out in big endian order (also known as most significant byte first , or network byte order ). 整数を表す複数オクテットのfieldはビッグエンディアン、ネットワークバイトオーダー、最上位バイトが最初である。 Kaufman, et al. Standards Track [Page 70] RFC 5996 IKEv2bis September 2010 The format of the IKE header is shown in Figure 4. IKE headerのフォーマットをFigure 4に示す。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE SA Initiator s SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE SA Responder s SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | MjVer | MnVer | Exchange Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 IKE Header Format o Initiator s SPI (8 octets) - A value chosen by the initiator to identify a unique IKE Security Association. This value MUST NOT be zero. IKE Security Associationを識別するため、initiatorによって選択された値。0であってはならない。 o Responder s SPI (8 octets) - A value chosen by the responder to identify a unique IKE Security Association. This value MUST be zero in the first message of an IKE initial exchange (including repeats of that message including a cookie). IKE Security Associationを識別するため、responderによって選択された値。IKE initial exchangeの最初のメッセージでは0であること(cookieを含むメッセージの繰り返しを含む。)。 o Next Payload (1 octet) - Indicates the type of payload that immediately follows the header. The format and value of each payload are defined below. headerの後に続くpayload typeを示す。各payloadのフォーマットと値を以下に示す。 o Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the major version to 2. Implementations based on previous versions of IKE and ISAKMP MUST set the major version to 1. Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2 with an INVALID_MAJOR_VERSION notification message as described in Section 2.5. IKEのメジャーバージョンを示す。本ドキュメントに基づく実装はIKEはメジャーバージョン2。前のIKEバージョン、ISAKAMPはメジャーバージョン1。Section 2.5のとおり、2より大きいメジャーバージョンにはINVALID_MAJOR_VERSION notification messageを通知しメッセージを拒否するか、無視することすること。 o Minor Version (4 bits) - Indicates the minor version of the IKE protocol in use. Implementations based on this version of IKE MUST set the minor version to 0. They MUST ignore the minor version number of received messages. IKEのマイナーバージョンを示す。本ドキュメントに基づく実装のIKEはマイナーバージョン0を設定すること。受信したマイナーバージョンは無視すること。 Kaufman, et al. Standards Track [Page 71] RFC 5996 IKEv2bis September 2010 o Exchange Type (1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message in an exchange. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. typeを示す。この値により送信するpayloadが制限される。下記の表はRFC4306発行時点の値である。今後、他の値が追加されるかもしれない。最新の値は[IKEV2IANA]参照。 Exchange Type Value ---------------------------------- IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 INFORMATIONAL 37 o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit in the flags field being set. The bits are as follows メッセージに設定される特別なオプションを示す。オプションは下記のbitフィールドで示される。 +-+-+-+-+-+-+-+-+ |X|X|R|V|I|X|X|X| +-+-+-+-+-+-+-+-+ In the description below, a bit being set means its value is 1 , while cleared means its value is 0 . X bits MUST be cleared when sending and MUST be ignored on receipt. 下記の説明では、setは1、clearedは0を意味する。Xは送信時にclearedされること、また受信側では無視すること。 * R (Response) - This bit indicates that this message is a response to a message containing the same Message ID. This bit MUST be cleared in all request messages and MUST be set in all responses. An IKE endpoint MUST NOT generate a response to a message that is marked as being a response (with one exception; see Section 2.21.2). このメッセージが同じMessage IDの応答であることを示す。このビットはrequest messageではclearedし、response messageではsetすること。IKEエンドポイントはresponseに対してresponseを生成しないこと。(例外はSection 2.21.2参照) * V (Version) - This bit indicates that the transmitter is capable of speaking a higher major version number of the protocol than the one indicated in the major version number field. Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages. 送信者がmejaor version number fieldの番号より高いメジャーバージョンを使用できることを示す。IKEv2の実装では送信側はこのビットをclearedし、受信側はこれを無視すること。 * I (Initiator) - This bit MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA. IKE SAのinitiatorによりsetして送信され、responderが送信するときclearedされること。受信者に、受信者によって8ビットのSPIが生成されたかを判断するために使用される。IKE SA rekeyをした場合、rekeyを開始したユーザがinitiatorになる。 Kaufman, et al. Standards Track [Page 72] RFC 5996 IKEv2bis September 2010 o Message ID (4 octets, unsigned integer) - Message identifier used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks. See Sections 2.1 and 2.2. 損失パケットの再送および要求/応答のメッセージのマッチングのために使用される。メッセージリプレイ攻撃を防ぐために不可欠。詳細はSection 2.1、2.2参照。 o Length (4 octets, unsigned integer) - Length of the total message (header + payloads) in octets. メッセージ(header+payload)のオクテット長。 3.2. Generic Payload Header Each IKE payload defined in Sections 3.3 through 3.16 begins with a generic payload header, shown in Figure 5. Figures for each payload below will include the generic payload header, but for brevity, the description of each field will be omitted. Section 3.3～Section 3.16で定義されたIKE payloadはFigure 5のgeneric payload headerではじまる。各payloadの図にはgeneric paylaodが含まれるが、記載の簡略化のため説明は省略する。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Generic Payload Header The Generic Payload Header fields are defined as follows Generic Payload Header filedは下記のように定義される。 o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides a chaining capability whereby additional payloads can be added to a message by appending each one to the end of the message and setting the Next Payload field of the preceding payload to indicate the new payload s type. An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads. In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of 0); conversely, the Next Payload field of the last contained payload is set to zero). The payload type values are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 次のpayload typeの識別子。このpaylodaが最後の場合、値は0になる。追加のpayloadを Next Payload に設定することでpayloadを繋げるchainingの機能を提供する。 Encrypted payloadは必ず最後のpayloadになる。これには追加のpayloadのデータ構造を含んでいる。Encrypted payloadのヘッダーのNext Payload fieldには最初に含まれるpayloadのpaylaod typeが設定される(0ではない)。そして、最後のpayloadのNext Payload fieldは0が設定される。（Encrypted paylaodの中には暗号化されたpayloadが続く的な意味。） Payload typeを下記に示す。下記はRFC4306発行時点のものである。最新の値は[IKEV2IANA]参照。 Kaufman, et al. Standards Track [Page 73] RFC 5996 IKEv2bis September 2010 Next Payload Type Notation Value -------------------------------------------------- No Next Payload 0 Security Association SA 33 Key Exchange KE 34 Identification - Initiator IDi 35 Identification - Responder IDr 36 Certificate CERT 37 Certificate Request CERTREQ 38 Authentication AUTH 39 Nonce Ni, Nr 40 Notify N 41 Delete D 42 Vendor ID V 43 Traffic Selector - Initiator TSi 44 Traffic Selector - Responder TSr 45 Encrypted and Authenticated SK 46 Configuration CP 47 Extensible Authentication EAP 48 (Payload type values 1-32 should not be assigned in the future so that there is no overlap with the code assignments for IKEv1.) IKEv1の割り当てと重複がないように、Payload type value 1-32は割り当てないこと。 o Critical (1 bit) - MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type. MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the next payload whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the critical bit s value. Skipped payloads are expected to have valid Next Payload and Payload Length fields. See Section 2.5 for more information on this bit. 前のpayloadのNext Payload filedを理解できない場合、送信者が受信者にpaylaodを無視して欲しい場合、0を設定する。送信者がPayload typeを理解できない場合、受信者にメッセージ全体を拒否して欲しい場合、1に設定すること。受信者がPaylaod Typeを理解している場合、受信者はこれを無視すること。このドキュメントで定義されたpayload typeの場合は0を設定すること。Critical bitはこのpayloadではなく、Next paylaodのtype codeに適用されることに注意せよ。このドキュメントで定義されたpayloadにCritical bitを設定しない理由は、実装ではこの文章に定義されたすべてのPayload Typeを理解する必要があるため、Critical bitは無視されるべきであるため。無視されたpayloadも正しいNext Payload TypeとPayload Lengthが設定されること。このビットの詳細についてはSection 2.5参照。 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on receipt. 0を設定し、受信側は無視すること。 o Payload Length (2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header. Generic payload headerを含む、このpaylaodのオクテット長。 Many payloads contain fields marked as RESERVED . Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 4-octet boundaries. 多くのpayloadは RESERVED fieldを含む。IKEv2のいくつかのpaylaodは4-octet アライメントされていない。 3.3. Security Association Payload The Security Association payload, denoted SA in this document, is used to negotiate attributes of a Security Association. Assembly of Security Association payloads requires great peace of mind. An SA payload MAY contain multiple proposals. If there is more than one, they MUST be ordered from most preferred to least preferred. Each proposal contains a single IPsec protocol (where a protocol is IKE, ESP, or AH), each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes. When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload s internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable-length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains. Security Association paylaodはSAと表記され、Security Associationのattributeをネゴシエーションするために使用される。Security Association paylaodの組み立てには細心の注意を必要とする。SA payloadは複数のproposalを含んでもよい。1つ以上ある場合、よい順で並べること。proposalは単一のIPsec protocol(IKE、ESP/AH)を含み、各プロトコルは複数のtransformが含まれてよく、各transformには複数のattributeが含まれてよい。SAをパースするとき、実装はすべてのPayloda Lengthがpayload内のPayload Lengthと一致することを確認すること。Proposal、Transform、Attributeは可変長のエンコーディング形式をもっている。SAのPayload LengthはネストしたProposal、Transform、Attributeを含む。Proposalのlengthはそれに含まれるすべてのTransform、Attributeを含む。Transformのlengthはそれに含まれるすべてのAttributeを含む。 The syntax of Security Associations, Proposals, Transforms, and Attributes is based on ISAKMP; however, the semantics are somewhat different. The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA. Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. For example, an initiator might want to propose using ESP with either (3DES and HMAC_MD5) or (AES and HMAC_SHA1). Association、Proposal、Transform、Attirbuteのシンタックス(構文)はISKAMPにもとづいている。ただしセマンティクス(意味)はやや異なる。複雑化、階層化の理由は一つのSAで複数のアルゴリズムの組み合わせのエンコーディングを可能とするためである。複数のアルゴリズムを組み合わせることが可能である。例えば、initiatorは(3DES/HMAC_MD5) or (AES/HMAC_SHA1)でESPを提案できる。 One of the reasons the semantics of the SA payload have changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases. SA paylaodがISAKMP、IKEv1から変更されている理由の一つはエンコードを単純にするためである。 The Proposal structure contains within it a Proposal Num and an IPsec protocol ID. Each structure MUST have a proposal number one (1) greater than the previous structure. The first Proposal in the initiator s SA payload MUST have a Proposal Num of one (1). One reason to use multiple proposals is to propose both standard crypto ciphers and combined-mode ciphers. Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and MUST either offer no integrity algorithm or a single integrity algorithm of none , with no integrity algorithm being the RECOMMENDED method. If an initiator wants to propose both combined- mode ciphers and normal ciphers, it must include two proposals one will have all the combined-mode ciphers, and the other will have all the normal ciphers with the integrity algorithms. For example, one such proposal would have two proposal structures. Proposal 1 is ESP with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an 8-octet Integrity Check Value (ICV). Both proposals allow but do not require the use of ESNs (Extended Sequence Numbers). This can be illustrated as Proposal構造体はProposal NumとIPsec protocol IDを含む。各構造体は前の構造体よりも1大きいProposal Numberが必要である。initiaorのSA payloadの最初のProposalはProposal Numが1であること。複数のproposalを使用する理由の一つはstandard crypto cipherとcombined-mode cipherの両方を提案できることである。Combined-mode cipherはintegrityとencryptionの両方を含む一つのencryption algorithmである。integrity algorithmはRECOMMENDEDのため、integrity algorithmなし or none のintegrity algorithmのみは提供しないこと。initiatorがcombined-mode cipherとnormal cipherの両方を提案する場合、両方をproposalに含めること。一つはすべてのcombined-mode cipherをもち、もう一つはintegrity algorithmをもつnormal cipherをすべてもつ。例えば、このようなproposalは2つのproposal構造をもつ。 Proposal1はESP with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity algorithmである。 Proposal2はAES-128 or AES-256 in GCM mode with an 8-octet Integrity Check Value (ICV)である。両方のproposalの提案は許容されるが、ESN(Extended Sequence Number)の使用は要求されない。下記のように示される。 SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | | 7 transforms, SPI = 0x052357bb ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | | | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) | +-- Transform ESN ( Name = ESNs ) | +-- Transform ESN ( Name = No ESNs ) | +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | 4 transforms, SPI = 0x35a1d6f2 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 256 ) | +-- Transform ESN ( Name = ESNs ) +-- Transform ESN ( Name = No ESNs ) Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has two transforms Extended Sequence Numbers (ESNs) and an integrity check algorithm. ESP generally has three ESN, an encryption algorithm, and an integrity check algorithm. IKE generally has four transforms a Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, and an encryption algorithm. For each Protocol, the set of permissible transforms is assigned Transform ID numbers, which appear in the header of each transform. 各Proposal/Protocol構造には1つ以上のTransform構造が続く。Transformの数はProtocolによって決定される。一般にAHには2つのTransformがある。Extended Sequence Number(ESN)、integrity check algorithm。一般的にESPには3つのTransformがある。ESN、encryption algorithm、integrity check algorithm。一般的にIKEには4つのTransformがある。Diffie-Hellman group、integrity check algorithm、PRF algorithm、encryption algorithm。各Protocolの許容するTransformは各Transform headerにあるTransform ID numberで割り当てられる。 If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or AES- CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as multiple transforms within a single Proposal. Instead, the initiator would have to construct two different Proposals, each with two transforms. 同じTransform Typeをもつtransformが複数ある場合、ProposalはそれらのTransformのORである。異なるTransform Typeをもつtransformが複数ある場合、ProposalはそれらのTransformのANDである。例： (3DES or AES-CBC) and (HMAC_MD5 or HMAC_SHA)のESPのProposalでは、2つの Transform Typeを含む。Transform Type 1 (one for 3DES and one for AEC-CBC) and Transform Type 3 (one for HMAC_MD5 and one for HMAC_SHA)である。これは実際は4つのalgorithmの組み合わせを提案している。initiatorがそれらのsubsetを提案したい場合は複数のTranfformを含めない。代わりに、initiatorは2つのProposalに2つのTransformを構成する必要がある。 A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes. A transform MUST NOT have multiple attributes of the same type. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), an implementation MUST include multiple transforms with the same Transform Type each with a single Attribute. Transformは1つ以上のAttirbuteをもってよい。Transformのencryption algorithmが可変長キーの場合などはAttributeが必要である。Transformは特定のalgorithmを指定した場合、Attiributeでkey sizeを指定する。多くのTransformはAttributeをもたない。Transformは同じタイプのAttiribureを複数もなたないこと。Attiributeの候補を提案する場合(例：AESで複数のキーサイズ)、実装は、一つのTransformに一つのAttributeを含めること。 Note that the semantics of Transforms and Attributes are quite different from those in IKEv1. In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes. TransformとAttirbuteのセマンティクス(意味)がIKEv1と異なることに注意せよ。IKEv1では、一つのTransformが複数のalgorithm、別のTransformがAttiributeを送信する。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Security Association Payload o Proposals (variable) - One or more proposal substructures. The payload type for the Security Association payload is thirty-three (33). 1つ以上のProposal構造。Security Association payloadのpayload typeは33である。 3.3.1. Proposal Substructure 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Proposal Substructure o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The value (2) corresponds to a payload type of Proposal in IKEv1, and the first four octets of the Proposal structure are designed to look somewhat like the header of a payload. SAの最後のProposal Substructureであることを示す。このシンタックス(構文)はISAKMPから継承されている。ただし、最後のProposalはSAのlengthから特定できるため不要である。 2はIKEv1におけるProposalのpayload typeで、Proposal structureの最初の4オクテットがpayloadのheaderになるように設計されている。 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on receipt. 0を設定し、受信者はこれを無視すること。 o Proposal Length (2 octets, unsigned integer) - Length of this proposal, including all transforms and attributes that follow. 以降に続くすべてのTransform、Attirbuteを含むProposalのLength。 o Proposal Num (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted. SA payloadの最初のProposalは1であること。その後のproposalは1より大きいこと（2つのproposalのORであることを示す）。proposalが許容されたときに、SA payloadのProposal Numberは許容されて送信されたProposal numberと一致していること。 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 現在ネゴシエーションしているIPsecのprotocol IDを示す。下記の表の値はRFC4306発行時のものである。他の値が追加される可能性もある。最新の値については[IKEV2IANA]参照。 Kaufman, et al. Standards Track [Page 78] RFC 5996 IKEv2bis September 2010 Protocol Protocol ID ----------------------------------- IKE 1 AH 2 ESP 3 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field MUST be zero; the SPI is obtained from the outer header. During subsequent negotiations, it is equal to the size, in octets, of the SPI of the corresponding protocol (8 for IKE, 4 for ESP and AH). initial IKE SAネゴシエーションではこの値は0であること。SPIはouter headerから取得する。ネゴシエーションにより対応するプロトコルのSPIのオクテットサイズが設定される(IKE 8、ESP/AH 4)。 o Num Transforms (1 octet) - Specifies the number of transforms in this proposal. このProposalにおけるTransformの数。 o SPI (variable) - The sending entity s SPI. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. When the SPI Size field is zero, this field is not present in the Security Association payload. 送信側のSPI。SPIのサイズが4オクテットの倍数でない場合でもpayloadではパディングしないこと。SPI Size fieldが0の場合はSecurity Association payloadにはこのフィールドは存在しない。 o Transforms (variable) - One or more transform substructures. 1つ以上のTransform構造。

p2rdj@ ウィキ - B1/神格

https://w.atwiki.jp/p2rdj/pages/682.html

神格 Bestiary 1 ゴグンタ［混沌にして悪］ Gogunta 沼地の歌出典 Bestiary 45ページ　「沼地の歌」ゴグンタは水陸両性のもの、ボガード、そして沼地のデーモン・ロードである。ゴグンタはボガードに女神として信仰されている。ボガードは彼女のことを神に昇格したモボゴであると信じているが、学者によれば彼女は元はヘズロウであり、ダゴンの恩寵を得たものだという。この学説を裏付けるように彼女の領土、悪臭放つ塩沼はダゴンの大海の領土の中にある。ゴグンタは巨大な多頭の蛙の姿で現れ、目はおろか下までも無数にある。しかしボガードは彼女のことを巨大なボガードの女王として描く。分類デーモン・ロード布告溺れさせてクリーチャーを生贄とせよ、沼地で戯れ歌え、水陸両性のものを食らい助けよ不義他の神を信仰するボガードに慈悲を与える関心のある範囲水陸両性のもの、ボガード、沼地信者の属性混沌にして悪信奉者の利益神泉危害信仰技能〈威圧〉好む武器ウィップ領域飽食、力、暴君、水クレリックの呪文 1レベル：ジャンプ、3レベル：スティンキング・クラウド、5レベル：ブラック・テンタクルズツリーレイザー［混沌にして悪］ Treerazer 爆破された小湖の王出典 Bestiary 312ページ　爆破された小湖の王、ツリーレイザーは自然の汚染と腐敗のデーモン・ロードに至ろうとするものである。デーモン・ロードに成り代わろうとして失敗した後に追放されたシス＝ヴサグによって排斥された従者あるいは落とし子だと多くのものに信じられている。ツリーレイザーはデーモン・ロードに至ろうとするものであり、真なるデーモン・ロードの力を備えてはいない。しかし彼はかつてエルフの国キョニンの南端にあった腐臭の沼、タングルブライアの中での物理的な存在感を持つ。そのため、そのような存在の中でゴラリオンに最も強い利害関係を持つ特筆すべき存在かもしれない。彼はキョニン国内とその近隣の熱狂的な信者に奉じられているが、ゴラリオンにはその昇格の際に彼の好意を得ようと、彼を解放しようと活動する信者の一派が見られる。ツリーレイザーの宗教印は半分に割られた血を流す枯れ木だ。区分デーモン・ロード布告植物の命を悪と菌類の繁茂で堕落させよ、エルフを殺せ、腐肉と菌類で宴を行え不義エルフを赦す、木を植える、自然の植物の成長を促す関心のある範囲自然の汚染と腐敗信者の属性中立にして悪、混沌にして悪信者の利益信仰能力値【筋力】もしくは【耐久力】神泉治癒もしくは危害信仰技能〈自然〉好む武器バトル・アックス領域破壊、自然、悪夢、暴君クレリックの呪文 1レベル：グリム・テンドリルズ、3レベル：ウォール・オヴ・ソーンズ、6レベル：タングリング・クリーパーズ Bestiary 2 イデルシウス［混沌にして悪］Ydersius 出典 Bestiary 2 237ページ The serpentfolk god is not dead, but in his decapitated state, he might as well be. Reduced to a feral, animalistic existence, Ydersius is even less aware of his legacy than the lowest of the aapoph. Ydersius’s symbol is a snake’s skull surrounded by a skeletal ouroboros. 分類 Other Gods 布告 seek to return Ydersius to life, fulfill your passions, conquer your foes with no mercy, achieve glory for serpentkind 不義 put the needs of others above those of serpentfolk, aid the spawn of Azlant 関心のある範囲 destiny, fate, and the aging process. 信者の属性 LE, NE, CE 信奉者の利益神泉危害信仰技能〈ペテン〉好む武器ダガー領域大望、飽食、力、闘魂クレリックの呪文 1レベル：マジック・ファング、5レベル：クラウドキル、6レベル：パープル・ワーム・スティングフォロワーズ・オヴ・フェイト［秩序にして中立］Followers of Fate 出典 Bestiary 2 185ページ On the Material Plane, some mortals worship norns as deities, while others, especially witches and bards, admire them as patrons or muses. Those who uphold norns as deities are known as Followers of Fate. Norns do little to discourage this veneration, but neither do they go out of their way to support such worship. Clerics who venerate norns might worship a specific norn or norn triumvirate, or all norns as a whole, but they gain the same benefits regardless of their choice. The religious symbol of Followers of Fate is a pair of shears cutting a golden thread, and their areas of concern are destiny, fate, and the aging process. 分類 Other Gods 布告 make predictions of the future, offer advice and guidance to those in positions of power, provide comfort to the elderly 不義 apologize for making an incorrect prediction, disrespect mothers, accept payment for fortune-telling 関心のある範囲 destiny, fate, and the aging process. 信者の属性 LG, LN, LE 信奉者の利益神泉治癒もしくは危害信仰技能〈伝承学〉好む武器大鋏領域家族、運命、知識、真実クレリックの呪文 1レベル：マインドリンク、3レベル：スリーフォールド・アスペクト、5レベル：プライング・アイ Bestiary 3 アーリマン（ディヴの王）［中立にして悪］Ahriman 出典 Bestiary 3 68ページ The dread shadow known as Ahriman counts servants mainly among div as well as a scattering of followers throughout the mortal realm. 分類 Other Gods 布告 Foil rulers, the proud, and the powerful; ruin anything created by mortals 不義 create arts or crafts, serve a mortal, assist in mortal aims except to subvert and corrupt them 信者の属性 LE, NE, CE 信奉者の利益神泉危害信仰技能〈ペテン〉好む武器ウィップ領域闇、死、破壊、欺きクレリックの呪文 1レベル：イル・オーメン、3レベル：ノンディテクション、5レベル：クラッシング・ディスペアグリーン・マン［中立］Green Man 出典 Bestiary 3 119ページ Individual green men are lesser deities, capable of granting spells to those who worship them. Green men typically only allow intelligent plants—such as leshys—to be their clerics. If another creature proves to be a friend of plants, after a thorough personal vetting, a green man wholeheartedly accepts this strange fleshy worshipper into the fold. While individual green men have different edicts and anathema befitting their personalities, and some neutral good or neutral evil green men might have further changes, the following is a baseline most worshippers of green men follow. 分類 Other Gods 布告 discover or create new forms of plant life, foster the growth and well-being of flora, preserve areas of natural wilderness 不義allow flagrant abuse of plant life to go unpunished, damage natural environments, harm plant life except in the pursuit of saving greater plant life 信者の属性 NG, N, NE 信奉者の利益神泉治癒信仰技能〈自然〉好む武器シックル領域治癒、力、自然、守護クレリックの呪文 1レベル：サモン・プラント・オア・ファンガス、2レベル：エンタングル、6レベル：タングリング・クリーパーズニャルラトホテプ（闇をさまようもの）［混沌にして悪］Nyarlathotep 出典 Bestiary 3 122ページ Nyarlathotep is often venerated by grioths in a bat-like incarnation with a three-lobed burning eye known as the Haunter in the Dark. His symbol is a circle with wing-shaped arms. 分類 Outer Gods and Great Old Ones 布告 Create darkness, encourage authorities to bring the apocalypse 不義 none 信者の属性 NE, CE 信奉者の利益神泉危害信仰技能〈伝承学〉好む武器ククリ領域闇、知識、悪夢、欺きクレリックの呪文 1レベル：グリム・テンドリルズ、4レベル：ナイトメア、5レベル：サモン・エンティティ

hoehoe's D&D Page - PC データ置き場/TORG Eternity キャンペーン PC

https://w.atwiki.jp/dnd4th/pages/142.html

TORG キャンペーン用キャラクター。 Francisca Fonseca Falque フランシスカ・フォンセカ・ファルケ ( ♀, 26 歳, スペイン人 ) 　Experience Points　 Gain Experience Points ： 180pts. Total Use ： 174pts. ： 96pts. = Gain 6 Perks ( 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 pts.) ： 9pts. = Gain 9 Skills ( 0 → 1 Rank ) ： 22pts. = Upgrade 11 Skills ( 1 → 2 Rank ) ： 12pts. = Upgrade 4 Skills ( 2 → 3 Rank ) ： 20pts. = Upgrade 5 Skills ( 3 → 4 Rank ) ： 15pts. = Upgrade 3 Skills ( 4 → 5 Rank ) 　出身コズム/アクシオムレベル　 Orrosh ( core earth tranceformed ) Magic ： 16 Social ： 18 Spirit ： 16 Tech ： 18 　Attributes　 Charisma ： 6 Dexterity ： 9 Mind ： 10 / 11 Spirit ： 8 Strength ： 7 　Skills　 Interaction Skills Intimidation [ Spirit ] ： Rank 1 ■◇◇◇◇ ( 9 ) Maneuver [ Dexterity ] ： Rank 1 ◆◇◇◇◇ ( 10 ) Taunt [ Charisma ] ： Rank 2 ◆◆◇◇◇ ( 8 ) Trick [ Mind ] ： Rank 2 ◆◆◇◇◇ ( 12 / 13 ) Combat Skills Energy Weapons [ Dexterity ] ： Rank 0 ◇◇◇◇◇ ( 9 ) Fire Combat [ Dexterity ] ： Rank 4 ■◆◆◆◇ ( 13 ) Heavy Weapons [ Dexterity ] ： Rank 0 ◇◇◇◇◇ ( 9 ) Melee Weapons [ Dexterity ] ： Rank 0 ◇◇◇◇◇ ( 9 ) Missile Weapons [ Dexterity ] ： Rank 2 ◆◆◇◇◇ ( 11 ) Unarmed Combat [ Dexterity ] ： Rank 2 ◆◆◇◇◇ ( 12 ) Magic Skills Alteration [ Mind ] ： Rank 5 ■■■◆◆ ( 15 / 16 ) Apportation [ Spirit ] ： Rank 0 ◇◇◇◇◇ ( -- ) Conjuration [ Spirit ] ： Rank 5 ◆◆◆◆◆ ( 13 ( 14 ) ) Divination [ Mind ] ： Rank 3 ■■■◇◇ ( 13 / 14 ) Other Skills Dodge [ Dexterity ] ： Rank 2 ◆◆◇◇◇ ( 11 ) Evidence Analysis [ Mind ] ： Rank 2 ■◆◇◇◇ ( 12 / 13 ) Find [ Mind ] ： Rank 1 ■◇◇◇◇ ( 11 / 12 ) Medicine [ Mind ] ： Rank 1 ■◇◇◇◇ ( 11 / 12 ) Scholar [ Mind ] ： Rank 2 ■◆◇◇◇ ( 12 / 13 ) Sience [ Mind ] ： Rank 3 ■■■◇◇ ( 13 / 14 ) Stealth [ Dexterity ] ： Rank 1 ◆◇◇◇◇ ( 10 ) Reality [ Spirit ] ： Rank 4 ■◆◆◆◇ ( 12 ) Willpower [ Spirit ] ： Rank 5 ◆◆◆◆◆ ( 13 ) 　Perks　 Spellcaster Medals ( Victoria Gloriana ) Bulletsmith Medals ( Defender ) Medals ( Carnifex Princeps ) Pulp Sorcerer Supreme Sorcery Instinctive Magic Trademark Weapon Bulletsmith Shells 　Magics　 Spell Name Axiom Skill Casting Time DN Range Duration Enhance 10 Alteration 12 1 Action Target s Attribute 40m 3 Rounds Speak with Dead 12 Divination 14 1 minute Standard ( DN 10 ) Touch 5 minutes Stun 12 Alteration 12 1 Action Target s Willpower or Spirit 50m Instant Blue Bands of Bastet 14 Conjuration 12 1 Action Target s Dodge or Dexterity 20m Concentration Figment 13 Conjuration 10 1 Action Standard ( DN 10 ) 50m Concentration 【 Equipment 】　Webley Revolver $300 　Monster Hide Duster $350 　Ammo Belt $50 　Alchemy Kit $200 　Tool Belt $100 　魔法の軟膏 ( 1 分かけて武器に塗ると、その武器はシーンの最後まで + 3 ダメージ ) 　義眼 ( 魔法の焦点具化、Conjuration + 1、魔法アクシオム 13 ) 【 Attacks 】 Webley Revolver Fire Combat 13 Range 10/25/40 14 Damage Ammo 6 Slayer s Gun ( Regular Shell ) Fire Combat 13 Range 50/100/200 14 Damage Ammo 6 3 x Adamant Shell 14 Damage AP 4 2 x Exprosive Shell 15 Damage Small Burst 1 x Giant Killer Shell 14 Damage + 5 damage against Large or greater creature 2 x Curse Shell 14 Damage Target Vulnerable. Next 1 minute, 【 Defenses 】　Dodge 15 / 16 ( Instinctive Magic により、最も高い Magic Skill の値を適用 ) 　Melee / Unarmed Defenses 11 　Total Toughness 9 ( 7 + 2 ), fatigued 　Shocks 8 　Wounds 3

ボードゲーム大賞まとめwiki - ドイツゲーム大賞/1

https://w.atwiki.jp/boardg/pages/16.html

１９９０年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 ADEL VERPFLICHTET Klaus Teuber F.X. Schmid 貴族の務め ○ 2 A LA CARTE Karl-Heinz Schmiel Moskito ア・ラ・カルト ○ 3 EIN SOLCHES DING Urs Hostettler/Fata Morgana Abacus 　　 4 Favoriten Walter Müller Müller お気に入り ○ 5 Goldrausch Reiner Knizia Hans im Glück ゴールドラッシュ ○ 6 Holiday AG Wolfgang Kramer F.X.Schmid ホリデイＡＧ ○ 7 Römer Rudolf Ross Hexagames ローマン ○ 8 Wind Wetter W.Dijkstra/B. van Dijk Jumbo メテオ ○ 9 Timberland Klaus Teuber Haba 　　 10 Dicke Kartoffeln D.Matthäus/F. Nestel Abacus じゃがいも畑 ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称発売元作者邦題 BW Life Style Ravensburger Ravensburger Redaktionsteam ライフスタイル ○ １９９１年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 LABYRINTH DER MEISTER Max Kobbert Ravensburger マスターラビリンス ○ 2 BAUERNSCHLAU Tom Schöps F.X. Schmid かしこい農夫 ○ 3 DRUNTER DRUEBER Klaus Teuber Hans im Glük ドルンター＆ドリューバー ○ 4 Jagd der Vampire Randolph u.a. Ravensburger バンパイアハンター ○ 5 Casablanca Eric Solomon Amigo カサブランカ ○ 6 Girl Talk F.X.Schmid ガールトーク　 7 Chamaleon Wolfgang Grokopf VSK カメレオン ○ 8 Duftende Spuren Ch. Heidorn/J. Heidorn Heidorn 　 ○ 9 Flusspiraten W. Mueller/K. Zoch Mueller 　 ○ 10 Columbus Wolfgang Kramer Ravensburger コロンブス ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Hotu Matua Reinhold Wittig Franckh-Kosmos 無　１９９２年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 DER FLIEGENDE HOLLAENDER Klaus Teuber Parker さまよえるオランダ人 ○ 2 UM REIFENBREITE Rob Bontenbal Jumbo ホーマス・ツアー ○ 3 QUO VADIS Reiner Knizia Hans im Glück クオ・ヴァディス ○ 4 Tal der König Christian Beierer Franckh-Kosmos 王家の谷 ○ 5 Schraumeln Urs Hostettler F.X. Schmid シュラウメルン ○ 6 Cosmic Encounter Eberle u.a. Hexagames コズミック・エンカウンター ○ 7 Minos Vanaise u.a. Ravensburger ミノス ○ 8 Extrablatt Karl-Heinz Schmiel Moskito エクストラブラット ○ 9 Razzia Stefan Dorra Ravensburger ラッツィア ○ 10 Neolithibum H. Bilz/P. Gutbrod Heidelberger 石器時代　 Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Coco Crazy Hajo Bücken Ravensburger ココ・クレイジー ○ Deutscher Kinderspiele Preis　子供ゲーム賞名称作者発売元邦題 BW Schweinsgalopp Heintz Meister Ravensburger オール・ザ・ウエイ・ホーム ○ １９９３年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 MODERN ART Reiner Knizia Hans im Glück モダンアート ○ 2 TUTANCHAMUN Reiner Knizia Amigo ツタンカーメン ○ 3 VERNISSAGE Klaus Teuber TM バーニサージ ○ 4 Bluff Richard Borg F.X.Schmid ブラフ ○ 5 Acquire Sid Sackson Schmidt アクワイヤ ○ 6 Rheingold Reinhard Herbert Jumbo ラインゴールド ○ 7 Spiel der Türme Rudi Hoffmann Schmidt 塔のゲーム ○ 8 Sticheln Klaus Palesch Amigo シュティヒェルン ○ 9 Empire 　 Welt der Spiele 　 10 Pfusch Bilz u.a. Heidelberger 手抜き工事 ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Acquire Sid Sackson Schmidt アクワイヤ ○ Deutscher Kinderspiele Preis　子供ゲーム賞名称作者発売元邦題 BW VERFLIXT GEMIXT Heinz Meister Ravensburger 　　１９９４年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 6 NIMMT Wolfgang Kramer Amigo シックス・ニムト ○ 2 CAPONE M. Caines/A. Watts Amigo カポネ ○ 3 MANHATTAN Andreas Seyfarth Hans im Glük マンハッタン ○ 4 Intrige Stefan Dorra F.X.Schmid イントリーグ ○ 5 Rette sich wer kann Ronald Wettering Müller 逃げろや逃げろ ○ 6 Was sticht Karl-Heinz Schmiel Moskito 蜂の一刺し ○ 7 Auf Heller und Pfennig Reiner Knizia Hans im Glück 最後の一文 ○ 8 Knock Out Wolfgang Panning TM ノックアウト ○ 9 Take it easy Peter Burley F.X.Schmid テイク・イット・イージー ○ 10 Billabong Eric Solomon Amigo ビラボンク ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Neue Spiele im alten Rom Reiner Knizia Piatnik 古代ローマの新ゲーム ○ Deutscher Kinderspiele Preis　子供ゲーム賞名称作者発売元邦題 BW HUSCH, HUSCH, KLEINE HEXE Heinz Meister F.X.Schmid 　　 Sonderpreis Aktionsspiel　アクションゲーム賞名称作者発売元邦題 BW LOOPING LOUIE Wiseley u.a. MB クルクルケッコー ○ １９９５年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 DIE SIEDLER VON CATAN Klaus Teuber Kosmos カタンの開拓 ○ 2 LINIE 1 Stefan Dorra Goldsieber １号線 ○ 3 STERNENHIMMEL Tom Schöps Goldsieber 天空のお星様 ○ 4 Die Maulwurf Company V. Charves/B.Kaes Ravensburger もぐれ！もぐら ○ 5 Medici Reiner Knizia Amigo メディチ ○ 6 Galopp Royal Klaus Teuber Goldsieber ギャロップ・ロイヤル ○ 7 Buzzle Eberle u.a. Franjos 　　 8 Hattrick Klaus Palesch Amigo ハットトリック ○ 9 Set Marsha J. Falco F.X.Schmid セット ○ 10 High Society Reiner Knizia Ravensburger ハイ・ソサエティ ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Die Siedler von Catan Klaus Teuber Kosmos カタンの開拓 ○ Deutscher Kinderspiele Preis　子供ゲーム賞　名称作者発売元邦題 BW PIEPMATZ Charles Girsch F.X.Schmid 　　１９９６年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 EL GRANDE W. Kramer R. Ulrich/Hans im Glück エル・グランデ ○ 2 ENTDECKER Klaus Teuber Goldsieber エントデッカー ○ 3 CARABANDE Jean du Po�l Goldsieber カラバンデ ○ 4 Reibach Co A. Moon/P. Gehrmann F.X. Schmid ぼろもうけカンパニー ○ 5 Mü D. Matthäus/F. Nestel Spiele von Doris Frank ミュー ○ 6 Marracash Stefan Dorra Kosmos マラケッシュ ○ 7 Yucata Hans im Glück ユカタン ○ 8 Campanile H. Kuhn/W. Kuhn Blatz カンパニーレ ○ 9 Ab die Post H. Huber/H. Huber Goldsieber アプ・ディー・ポスト ○ 10 Top Race Wolfgang Kramer ASS トップレース ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Top Race Wolfgang Kramer ASS トップレース ○ Deutscher Kinderspiele Preis 子供ゲーム賞名称作者発売元邦題 BW HALLO DACHS Klaus Teuber Goldsieber 　 ○ １９９７年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 L OUML;WENHERZ Klaus Teuber Goldsieber ライオンハート ○ 2 DIE SIEDLER VON CATAN DAS KARTENSPIEL Klaus Teuber Kosmos カタン・カードゲーム ○ 3 SHOWMANAGER Dirk Henn Queen ショウマネージャー ○ 4 Mississippi Queen Werner Hodel Goldsieber ミシシッピクイーン ○ 5 Bohnanza Uwe Rosenberg Amigo ボーナンザ ○ 6 Serenissima D. Erhard/D. Vitale Eurogames セレニッシマ ○ 7 Der Zerstreute Pharao Gunter Baars Ravensburger 　 ○ 8 Expedition Wolfgang Kramer Queen エクスペディション ○ 9 Beim Zeus Klaus Palesch Kosmos ゼウスにかけて ○ 10 Manitou Günter Burkhardt Goldsieber マニトウ ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者発売元邦題 BW Mississippi Queen Werner Hodel Goldsieber ミシシッピクイーン ○ Deutscher Kinderspiele Preis　子供ゲーム賞名称作者発売元邦題 BW DIE RITTER VON DER HASELNUSS Klaus Teuber Goldsieber ヘーゼルナッツの騎士 ○ １９９８年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 Euphrat Tigris Reiner Knizia Hans im Glück チグリス＆ユーフラテス ○ 2 Ursuppe D. Matthäus/F. Nestel Doris Frank 原始スープ ○ 3 Elfenland Alan Moon Amigo エルフェンランド ○ 4 Durch die Wüste Reiner Knizia Kosmos 砂漠を越えて ○ 5 Canyon Frederik A.Herschler Abacus キャニオン ○ 6 Freibeuter Reiner Stockhausen Hans im Glück 海賊 ○ 7 Die Macher 　 Hans im Glück 黒幕 ○ 8 Tycoon Wolfgang Kramer Jumbo タイクーン ○ 9 Städte Ritter Wolfgang Kramer Kosmos 都市と騎士 ○ 10 Caesar Creopatra Wolfgang Lüdtke Goldsieber シーザとクレオパトラ ○ Deutscher Kinderspiele Preis　子供ゲーム賞名称作者発売元邦題 BW Zicke Zacke Hünerkacke Klaus Zoch Zoch 　　１９９９年　　　　　ページ先頭へ順位名称作者発売元邦題 BW 1 Tikal Wolfgang Kramer Ravensburger ティカル ○ 2 RA Reiner Knizia Alea ラー ○ 3 Union Pacific Alan Moon Amigo ユニオン・パシフィック ○ 4 Samurai Reiner Knizia Hans im Glück サムライ ○ 5 Die Händler Wofgang Kramer Queen 貿易者 ○ 6 Giganten Wilko Manz Kosmos ギガンテン ○ 7 Verräter Marcel-Andre Casasola Adlung 裏切り ○ 8 Mamma Mia Uwe Rosenberg Abacus マンマ・ミーア ○ 9 Chinatown Karsten Hartwig Alea チャイナタウン ○ 10 Pfeffersäcke Christwart Conrad Goldsieber 胡椒袋 ○ Deutscher Kinderspiele Preis　子供ゲーム賞名称作者発売元邦題 BW Kayanak Peter-Paul Joopen Haba カヤナック　２０００年　　　　　ページ先頭へ順位名称作者メーカー邦題 BW 1 Taj Mahal タージマハール 2 Torres Wolfgang Kramer Michael Kiesling FX/Ravensburger トーレス 3 Vinci The Rise and Fall of Civilizations ヴィンチ 4 Die Fursten von Florenz Wolfgang Kramer Richard Ulrich ALEA/Ravensburger フローレンスの領主 5 La Citta Gerd Fenchel Kosmos ラ・チッタ 6 Ohne Furcht und Adel 完全無欠の騎士 7 Kardinal Konig Michael Schacht Gold Sieber 王と枢機卿 ○ 8 Carolus Magnus Leo Colovini Winning Moves カール大帝 9 Aladdin s Dragons アラジンの竜 10 Die Kaufleute von Amsterdam アムステルダムの商人 Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称発売元作者邦題 BW Tadsch Mahal Reiner Knizia ALEA タージ・マハール ○ Kinderspiel 　子供ゲーム賞名称発売元作者邦題 BW Piraten-Pitt Wolfgang Kramer HABA ２００１年　　　　　ページ先頭へ順位名称作者メーカー邦題 BW 1 Carcassonne K.-J. Wrede Hans im Gluck カルカソンヌ ○ 2 Medina Stefan Dorra Hans im Gluck ○ 3 The Traders of Genoa Die Handler von Genua Alea ジュネーブの商人 ○ 4 Evo エヴォ ○ 5 Capitol キャピトル ○ 6 Cartagena カルタヘナ ○ 7 San Marco サンマルコ ○ 8 Babel バベル ○ 9 Java ジャワ ○ 10 Das Amulett アミュレット ○ Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称発売元作者邦題 BW Die neuen Entdecker Klaus Teuber Kosmos ニュー・エントデッカー ○ Kinderspiel 　子供ゲーム賞名称発売元作者邦題 BW Zapp Zerapp KH. Meister K. Zoch Zoch ザップ・ゼラップ ○ Sonderpreis 　特別賞名称発売元作者邦題 BW SPIELE-AUTOREN-ZUNFT 　　２００２年　　　　　ページ先頭へ順位名称作者メーカー邦題 BW 1 Puerto Rico Andreas Seyfarth Alea プエルト・リコ ○ 2 Trans America Franz-Benno Delonge Winning Moves トランス・アメリカ ○ 3 Dschunke Michael Schacht Queen Games ジャンク 4 Villa Paletti Bill Payne Zoch ヴィラ・パレッティ 5 Mexica Wolfgang Kramer y Michael Kiesling Ravensburger メキシカ 6 Nautilus Wolfgang y Brigitte Ditt Kosmos ノーチラス 7 Goldland Wolfgang Kramer Goldsieber ゴールドランド 8 Pueblo Wolfgang Kramer y Michael Kiesling Ravensburger プエブロ 9 Piratenbutch Paul Randles y Daniel Stahl Amigo 　 10 Magellan Tom Lehmann Hans im Gluck マゼラン Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称発売元作者邦題 BW Puerto Rico Andrea Seyfarth Alea/Ravensburger プエルト・リコ Kinderspiel 　子供ゲーム賞名称作者メーカー邦題 BW Hoechst verdachtig M. Ludwig HABA ２００３年　　　　　ページ先頭へ順位名称作者メーカー邦題 BW 1 Amun Re Reiner Knizia Hans im Gluck アメン・ラー 2 Alhambra Dirk Henn Queen Games アルハンブラ 3 Clans Leo Colovini Winning Moves クランス 4 Paris Paris パリ・パリ 5 Domaine 6 Fische Fluppen Frikadellen 7 Mare Nostrum 8 New England ニュー・イングランド 9 Coloretto コロレット 10 Edel,Stein Reich Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称発売元作者邦題 BW Der Palast von Alhambra Dirk Henn Queen Games Kinderspiel 　子供ゲーム賞名称作者メーカー邦題 BW Schloss Schlotterstein K. Haferkamp M. Nikisch HABA ２００４年　　　　　ページ先頭へ順位名称作者メーカー邦題 BW 1 St.Petersburg Michael Tummelhofer Hans im Glueck サンクト・ペテルスブルク ○ 2 San Juan A.Seyfarth alea サンファン ○ 3 Goa R. Dorn Hans im Gluck ゴア ○ 4 Attika M-A.Casasola Mercle Hans im Gluck アッチカ 5 Ingenious 6 Genial Reiner Knizia Kosmos 6 Ticket to Ride Alan.R.Moon Days of Wonder チケット・トゥ・ライド ○ 7 Maharaja W.Kramer M.Kiesling Phalanx マハラジャ 8 Fearsome Floors Friedman Friese 2F 暗黒の大広間 9 Hansa Michael Schacht Abacus ハンザ 10 The Brides of Shangri-La Wolfgang Kramer Kosmos Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者メーカー邦題 BW Fifth Avenue W.Manz alea ５番街 Kinderspiel 　子供ゲーム賞名称作者メーカー邦題 BW Dicke Luft in der Gruft N. Proena Zoch 墓場の吸血鬼２００５年　　　　　ページ先頭へ順位名称作者メーカー邦題 BW 1 Louis XIV Rudiger Dorn alea/Ravensburger ルイ１４世 2 Niagara Thomas Liesching Zoch ナイアガラ ○ 3 Manila Franz-Benno Delonge Zoch マニラ 4 Ubongo Grzegorz Rejchtman Kosmos ウボンゴ 5 Himalaya Regis Bonnessee Tilsit Editions ヒマラヤ 6 Around the World in 80 Days Michael Rieneck Kosmos 80日間世界一周 7 Shadows Over Camelot Bruno Cathala und Serge Laget Days of Wonder 8 Jambo Rudiger Dorn Kosmos 9 Das Zepter von Zavandor Jens Drogemuller Lookout Games 10 VERFLIXXT! Michael Kiesling und Wolfgang Kramer Ravensburger Spiel mit der besten Regel ( Goldene Feder ) 　金の羽根賞（ベストルール）名称作者メーカー邦題 BW Piranha Pedro J.-P. Schliemann Goldsieber Kinderspiel 　子供ゲーム賞名称作者メーカー邦題 BW Akaba G. Hoffmann HABA-Habermaas

amanattou @ ウィキ - _vimperator

https://w.atwiki.jp/amanattou/pages/13.html

"3.0 (created 2011/03/06 22 51 04) source! "C \\Users\\aa\\_vimperatorrc.local" "set runtimepath="C \\Users\\aa\\vimperator" "source! "C \\Program Files (x86)\\Mozilla Firefox\\plugins\\_smooziee.js" "source! plugins\_smooziee.js "source! "C \\Users\\aa\\vimperator\\_smooziee.js" "source C \Users\aa\vimperator\plugin\_smooziee.js "set loadplugins " vim set ft=vimperator "+-----------------------------------------------------------------------------+ " 基本設定 "+-----------------------------------------------------------------------------+ "ブラウザタイトルの変更 set titlestring=Firefoxb "メニュー/ツール/リンクを表示 set gui=noaddons,nobookmarks,menu,navigation,tabs "ページ全体で検索語を強調表示 set hlsearch "ビープ音を鳴らさずビジュアルベルを使用 set visualbell "ビジュアルベルを無効化 "set visualbellstyle=display none; "検索キーワードのハイライト set hlsearch "ヒントのスタイルを指定 "set hintstyle=z-index 5000; font-family monospace; font-size 12px; color white; background-color blue; border-color ButtonShadow; border-width 0px; border-style solid; padding 0px 1px 0px 1px; position absolute; "ヒント(フォーカス時)のスタイルを指定 "set focusedhintstyle=z-index 5000; font-family monospace; font-size 12px; color ButtonText; background-color ButtonShadow; border-color ButtonShadow; border-width 1px; border-style solid; padding 0px 1px 0px 1px; position absolute; set nextpattern=^\次,^\続き,\bnext,^ $,^( \|??)$,^( \|??),( \|??),\bmore\b$ set previouspattern=^\前,^\戻,\bprev|previous\b,^ $,^( \|??)$,^( \|??),( \|??)$ "Hint モードで使用するキーを設定 "set hintchars=asdfjklgh "set hintchars=FJKLASDHGUIONMERWC set hintchars=fjklasdhguionmerwc hi -append Hint text-transform uppercase; hi Hint font-family monospace; font-size medium; font-weight bold; text-transform uppercase; line-height 1; color black; background-color #5FF; border-color ButtonShadow; border-width 1px; border-style solid; padding 1px; z-index 99999; hi -append CompDesc color #272; hi -append StatusLine color #44A; style -name commandline-ime chrome //* #liberator-commandline-command input {ime-mode inactive;} "colorscheme sweets_snaka "+-----------------------------------------------------------------------------+ " キーマップ設定 "+-----------------------------------------------------------------------------+ "yで選択範囲をコピー map y echo Yank! CR Y "j/kの移動量を5倍に map j 5 C-e map k 5 C-y "J/KにPageDown,PageUpを割り当て(LDRizeが効いている場合でも指のポジションを動かさずに済む noremap J PageDown noremap K PageUp " BS で「戻る」 map BS H " A-Left / A-Right かh/lでタブ移動 "map A-Left C-p "map A-Right C-n map h C-p map l C-n " A-Down で現在のタブを閉じる "map A-Down d " S-Left / S-Right で現在のタブの位置変更 "map S-Left tabmove! -1 CR "map S-Right tabmove! +1 CR "sで現在のページを保存 "map s saveas CR " OSのキーバインドを再現 "noremap C-a C-v C-a "noremap C-c C-v C-c "inoremap C-a C-v C-a "inoremap C-c C-v C-c "inoremap C-v C-v C-v "inoremap C-x C-v C-x "inoremap C-z C-v C-z "cnoremap C-a C-v C-a "cnoremap C-c C-v C-c "cnoremap C-v C-v C-v "cnoremap C-x C-v C-x "cnoremap C-z C-v C-z "noremap C-q C-v "inoremap C-q C-v "検索バーにフォーカス "map C-k C-v C-k map C-k i C-k "ロケーションバーにフォーカス map C-l A-d "お気に入り "map C-d C-v C-d map C-d i C-d "これで、dキーでタブを閉じた時は直前にフォーカスしていたタブに戻ってくれます。 map d C-w " URL中の数字を++/-- noremap ++ C-a noremap -- C-x "選択中の語句で検索する "vmap C-S-f y Esc Esc P "map C-S-f y Esc Esc P "noremap C-S-f y Esc Esc P "inoremap C-S-f y Esc Esc P "cnoremap C-S-f y Esc Esc P vmap C-S-f C-c P map C-S-f C-c P noremap C-S-f C-c P inoremap C-S-f C-c P cnoremap C-S-f C-c P "+-----------------------------------------------------------------------------+ " プラグイン設定 "+-----------------------------------------------------------------------------+ " C-Del で検索語の強調表示をトグル(toggleHighlight.js) "map C-Del toggleHighlight CR " F2 でメニューバーをトグル(toggleToolbar-0.5.1.js) "map F2 toggleToolbar CR " C-S-c でタイトルとURLをコピー(copy.js) map C-S-c copy titleAndURL CR map C-r mapc CR cmapc CR imapc CR source C \Users\aa\_vimperatorrc CR " char_hints_mod2.js "let g hints io="io" "let g hintchars="HJKLASDFGYUIOPQWERTNMZXCVB" "+-----------------------------------------------------------------------------+ " 未プラグイン化スクリプト "+-----------------------------------------------------------------------------+

Team2ch DINGUX LocalPack計画（仮） - dingux-msx

https://w.atwiki.jp/dingux2ch/pages/29.html

トップページ Download エミュレータ dingux-msx Dingux-MSXパッケージ概要 Dingux-MSXのアイコンとdmenu.cfgを導入するパッケージです。 Dingux-MSX一式については、後述のオフィシャルサイトか一次配布元からダウンロードしてください。使用方法インストールする場合は、オフィシャルサイトからダウンロードしてきた最新のdingux-msx-v?.?.?0-bin.zip を解凍して、SDカードに上書きコピーした後、下記ダウンロードリンクの dingux-msx-pack.zip を解凍して出てきた dingux-msxフォルダを、SD \local\emulators\dingux-msx に上書きしてください。アンインストールする場合は、dingux-msxフォルダをSDカードから削除してください。ダウンロードリンク Download dingux-msx-pack.zip Mirror MegaUpload オフィシャルサイト／一次配布元／原作者／移植者オフィシャルサイト／一次配布元：http //zx81.zx81.free.fr/serendipity/index.php?/categories/108-MSX 原作者／移植者：ZX-81氏パッケージ製作者：1◆qbQD4T5Z0949 内容紹介 dmenu.cfg dingux-msx.png 追加アイコンデフォルトアイコン専用アイコン(by たつぼうさん) 更新履歴 2009/12/15 作成パッケージの評価選択肢投票 ☆☆☆☆ (0) ★☆☆☆ (0) ★★☆☆ (0) ★★★☆ (0) ★★★★ (0) コメント名前コメント

lsl備忘録 - llSetDamage

https://w.atwiki.jp/lslwiki/pages/299.html

llSetDamage llSetDamage(float damage) 機能概略サンプル Tips 詳細な説明 History 来客数：　 - 選択肢投票役に立った (0) 役立たずだった (0) 名前コメント

telespo @ ウィキ - ZIP!(木) 2023年7月～9月

https://w.atwiki.jp/telespo/pages/566.html

日本テレビ平日 ZIP!(木) 2023年7月～9月スポンサーリスト 2023年7月27日 A枠 0'30"…POLUS B枠 0'30"…MITSUBISHI MOTORS、第一三共ヘルスケア C枠 0'30"…ハウステンボス D枠カード提供…トーシンパートナーズ E枠 0'30"…日本メディアシステム、SUNSTAR、KOSE COSMEPORT F枠 0'30"…アイリスオーヤマ、住友生命 G枠 0'30"…三井不動産レジデンシャル、EneCle H枠 0'30"…アース製薬 I枠 1'00"…P G 0'30"…アクサ（アクサダイレクト）、ReFa、高須クリニック 🔶(8/3・19) 2023年8月3日 A枠 0'30"…POLUS B枠 0'30"…小林製薬、大樹生命 C枠 0'30"…ハウステンボス D枠カード提供…トーシンパートナーズ E枠 0'30"…KOSE COSMEPORT、日本メディアシステム、SUNSTAR F枠 0'30"…任天堂、NISSAN G枠 0'30"…EneCle、三井不動産レジデンシャル H枠 0'30"…RIZAP I枠 0'30"…家庭教師のトライ、エステー、UNIQLO、TCB、AJINOMOTO 🔶(当日・19) 2023年8月17日 A枠 0'30"…POLUS B枠 0'30"…大樹生命、小林製薬 C枠 0'30"…ハウステンボス D枠カード提供…トーシンパートナーズ E枠 0'30"…日本メディアシステム、SUNSTAR、KOSE COSMEPORT F枠 0'30"…NISSAN、任天堂 G枠 0'30"…EneCle、三井不動産レジデンシャル H枠 0'30"…HONDA I枠 0'30"…家庭教師のトライ、エステー、UNIQLO、TCB、AJINOMOTO 🔶(当日・22) 2023年9月7日 A枠 0'30"…POLUS B枠 0'30"…第一三共ヘルスケア、MITSUBISHI MOTORS C枠 0'30"…ハウステンボス D枠カード提供…トーシンパートナーズ E枠 0'30"…日本メディアシステム、SUNSTAR、KOSE COSMEPORT F枠 0'30"…住友生命、アイリスオーヤマ G枠 0'30"…三井不動産レジデンシャル、EneCle H枠 0'30"…ゼリア新薬 I枠 1'00"…P G 0'30"…アクサ（アクサダイレクト）、ReFa、高須クリニック 🔶(9/9・20) 2023年9月14日 A枠 0'30"…POLUS B枠 0'30"…小林製薬、SIXPAD(PT) C枠 0'30"…ハウステンボス D枠カード提供…トーシンパートナーズ E枠 0'30"…KOSE COSMEPORT、日本メディアシステム、SUNSTAR F枠 0'30"…NISSAN、任天堂 G枠 0'30"…EneCle、三井不動産レジデンシャル H枠 0'30"…明治 I枠 0'30"…家庭教師のトライ、エステー、UNIQLO、TCB、AJINOMOTO J枠 1'00"…カーネクスト 🔶(9/18・20) 2023年9月21日 A枠 0'30"…POLUS B枠 0'30"…MITSUBISHI MOTORS、第一三共ヘルスケア C枠 0'30"…ハウステンボス D枠カード提供…トーシンパートナーズ E枠 0'30"…SUNSTAR、KOSE COSMEPORT、日本メディアシステム F枠 0'30"…アイリスオーヤマ、住友生命 G枠 0'30"…三井不動産レジデンシャル、EneCle H枠 0'30"…日清食品 I枠 1'00"…P G 0'30"…ReFa、高須クリニック、アクサ（アクサダイレクト） J枠 1'00"…LOTTE 🔶(9/23・19)

Thunderstone @ ウィキ - Magical Aura

https://w.atwiki.jp/thunderstone/pages/54.html

Magical Aura/マジック・オーラカードタイプ：Village/村エキスパンション：Thunderstone/サンダーストーン英語版 Card Name Number Class Cost Gold Weight Light VP Text MAGICAL AURA 8 SPELL 4 2 DUNGEON All Weapons become Weight 0.Draw one card. 日本語版カード名枚数分類コスト金貨値重量明かり勝利点テキストマジック･オーラ 8 呪文 4 2 ダンジョン：すべての武器は重さ0になる。カード1枚を引く。カード解説/CARD GLOSSARY エラッタ日本語版「精霊獣の怒り」付属の仕切りカード名称が「マジカル･オーラ」になっているカード分析所感英語はMagical Aura。日本語はなぜかマジック･オーラ。仕切りカードのミスはここから来ている。呪文としては珍しい金貨値2持ち。村では金貨値、ダンジョンでは1枚ドローなので、購入によるマイナス要素は少ない。あとは重量軽減の効果を活かせるデッキにできるかどうか。全体化してドローの付いたIron Rations/保存食と考えると、立ち位置がわかりやすい。重量武器の質と、英雄達の体力次第で有効度が上下する。基本的に使い勝手がよいとはいえないが、構成次第では輝かせることも不可能ではない。重さ0の武器は体力が0になっていても持てる。また、体力がマイナスになっても実質0として扱うルールがあるため、Revenant/レヴナントや、Lich Lord/リッチ･ロードなどマイナス修正の大きい相手には有用となることも。シナジー Nightblade/ナイトブレード：重さ3以下の鋭利武器は5種しかないが、マジック･オーラを使用することでそれ以外の鋭利武器でもボーナスが得られるようになる。Claymore/クレイモアを振り回す暗殺者･･･ロマンですな。 Frost Giant Axe/フロスト･ジャイアント･アックス：あえて体力値の高い英雄を採用せずに、アックスのドローを最大限に活かす。アンチシナジー Polearm/ポールアーム：体力が増すわけでもなく、もともと軽いので重量軽減効果もおいしくない。得意なモンスター苦手なモンスター Thunderstone Advance対応版 ※Download Thunderstone Print and Play企画版。 http //www.alderac.com/thunderstone/2012/05/26/download-thunderstone-print-and-play/　参照。 Card Name Number Class Cost Gold Weight Light VP Text Magical Aura 8 Spell･Support 4 2 Dungeon All weapon Weights become 0. Draw 1 card. 能力自体はクラシック版から変更無し。Support属性が付いたくらい。